buildpacks - by name + git url fallback

[drnic]

What's the user value of this feature request?

manifest.yml can list a set of buildpacks; but each buildpack can only be listed by either its git url, or its zip URL, or a name if its installed by a platform operator.

This makes it very hard for sample or shared applications, such as https://github.com/starkandwayne/wordpress-for-cloudfoundry, that must provide multiple manifests because they don't know if a target CF will have pre-installed buildpacks or not.

• https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.yml - manifest with git urls for new buildpack; but these are slow buildpacks since they build libbuildpack bits from source
• https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.buildpacks.yml - manifest with named buildpacks; but this requires that the user has convinced the platform operator to install the new buildpacks
• another example could be a manifest.yml that has explicit urls to .zip files

Instead, I propose that we change the schema of buildpacks to something like routes - where each item is an object, rather than a simple string; and to allow use to provide all the information about a buildpack:

applications:
- name: wp
  buildpacks:
  - name: pancake_buildpack
    source: https://github.com/starkandwayne/pancake-buildpack
  - name: wpcli_buildpack
    source: https://github.com/starkandwayne/wpcli-buildpack
  - name: php_buildpack  

Who is the functionality for?

Users of Cloud Foundry

How often will this functionality be used by the user?

Whenever deploying shared applications written by authors who do not know the status of your cf buildpacks list.

Who else is affected by the change?

An implementation could continue to support the existing buildpacks: [pancake_buildpack, php_buildpack] schema.

Is your feature request related to a problem? Please describe.

I don't like that I have to curate multiple manifests and document it in projects like https://github.com/starkandwayne/wordpress-for-cloudfoundry/

I'd prefer that users can get a pre-installed buildpack if it exists; or fallback to a git url if its missing.

Describe the solution you'd like

Support both the existing buildpacks: [name1, name2] and new buildpacks: [{name: name1, source: uri1}, {name: name2}].

Also continue to support name or git url in cf push -b name1 -b url2.

Describe alternatives you've considered

See https://github.com/starkandwayne/wordpress-for-cloudfoundry/ - I must curate multiple manifest.yml for end users and hope they understand the reason for each and when to switch.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/166267569

The labels on this github issue will be updated when the story is started.

[abbyachau]

Thanks @drnic. Tagging CAPI PMs who could consider this feature for V3/V7 feature development on the server side. We do not have any plans to make changes to the V6 CLI in favor of feature development on V7.

cc @ssisil @tcdowney

[abbyachau]

Thanks @drnic, I'm moving this issue to the CAPI repo since there are no further planned updates for the V6 CLI manifest.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/166385947

The labels on this github issue will be updated when the story is started.