Mike, thanks for sharing your thoughts.
I agree that it's also valuable to provide the runtime information for a pushed application.
For the use case of providing supported runtime by a buildpack, letting the user look at the doc to find out involves several steps: 1. do "cf buildpacks" to find out what version of the buildpack is installed in the cloud environment; 2. do a google search for that buildpack version 3. click the best hit, browse through the web page and find the information
As opposed to one command: cf buildpack <xyz-buildpack>. So to me obviously the command makes things so much easier.
The other potential use case is for a dev tool to query that information programmatically and then set up local dev environment accordingly. For example, the Eclipse tool can query the default JRE version used by the Java buildpack, and then use that JRE level to compile a local Java project.
Jack
toggle quoted messageShow quoted text
On Wed, Dec 16, 2015 at 4:37 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Hi, Jack! Thanks for bringing this up.
I agree we could and should be thinking about how to provide more metadata about the buildpacks. Some thoughts inline below.
On Mon, Dec 14, 2015 at 5:29 PM, Jack Cai <greensight(a)gmail.com> wrote:
Now that most buildpacks only support a small set of runtime versions (as defined in their manifest), it makes good sense to make this information easily accessible by users. They can of course go to the github project and open that manifest file, or read the doc, but I think the better way might be making that information accessible through API/CLI. We already have a set of API/CLI-commands for managing admin buildpacks. It seems pretty straightforward to add that support, e.g., allowing users to issue:
cf buildpack xyz_buildpack
which returns some descriptive information on supported runtime versions (and the default) in addition to existing information like index, enabled, etc. These descriptive information can be registered when "create-buildpack" is issued, either provided explicitly, or reading from a certain file in the buildpack package.
The information you're asking for, e.g. runtime versions, is pretty easily findable and readable from the release notes (e.g., https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.10). Is there a particular reason that you'd like to be able to access this information dynamically?
I can imagine a situation where a developer starts an app and wonders "What version of {ruby,php,python,node} should I use to make sure my app runs on my CF?"
We could address this situation by making the manifest information more easily available; but I think we're most of the way down an alternative path that addresses this situation in a way that Just Works:
Ideally, there won't be substantive functional differences between two patches on a major/minor branch (e.g., ruby 2.2.2 and 2.2.3 behave the same way, modulo bug fixes). I'd much prefer if we allowed developers to say, "Just use the most recent Ruby 2.2.x version you have".
Currently developers can do this with some of the buildpacks, notably:
* php-buildpack supports setting PHP_VERSION to variables like PHP_56_LATEST which are evaluated at staging time based on the buildpack's manifest. * nodejs-buildpack supports npm's version ranges, such as "~>0.12.0" or "4.2.*"
We have a story in motion to add this support to the Ruby buildpack <https://www.pivotaltracker.com/story/show/106008092>, which notably required us to send a PR into Bundler <https://github.com/bundler/bundler/pull/4064> to support version operators in Gemfiles. This PR was just accepted, and so the feature is unblocked.
We have another story in motion to add this support to the Go buildpack <https://www.pivotaltracker.com/story/show/106117500>, which notably required us to send a PR into Godep <https://github.com/tools/godep/pull/318> to support version operators in Godeps.json files. This PR hasn't been accepted yet, as the conversation is still ongoing over the best way to solve this issue.
We don't have any plans to add support for this to the Python buildpack, as `pip` doesn't support version operators, and we haven't heard anyone request it to justify the effort to submit the necessary changes to `pip`.
Does anybody like this idea? Can we add it to the backlog?
I have a hunch that it would be higher-value to provide buildpack information about how a specific app was staged, but would like to validate that hypothesis.
Many older and forked and non-core buildpacks don't emit identifying information from `bin/detect` and so it's impossible to tell what version of the buildpack was used once the app has been staged. Additionally, if I push with the `-b` option, even with an up-to-date buildpack, right now I still have no version information available.
How can I tell if I need to restage my app to address a vulnerability in one of the vendored binaries? Today, you can't.
It's possible that we could simply store the buildpack manifest contents, if available, as a record of what staged the application. I haven't thought deeply about what the simplest thing might be here, but would love to continue the conversation and bounce some ideas off you!
Jack
|