Expose functionality to download buildpacks

[jromero]

See comment below by requester @jabrown85

[jabrown85]

@jromero I can't edit this, so you'll need to move it.

Description

As a consumer of pack as a library, I want to be able use pack's ephemeral builder functionality in a similar way on a platform.

For instance, a user can run pack build --buildpack mybpimage:v2 myimg --builder heroku/buildpacks and pack will build an ephemeral image with the mpbpimage downloaded from dockerhub. There is a good bit of logic and decisions that pack makes when processing the --buildpack argument. Those decisions include determining if what was provided is an image, relative folder, tar, buildpackage, parsing versioning, etc. As a platform, it would be nice to be able to leverage some of that logic via pack as a library.

Aside: This example can also be expressed with a user using package.toml, which is maybe the more likely scenario.

Proposed solution

pack can expose some of the core methods used to create ephemeral builders as primitives.

Describe alternatives you've considered

Use pack itself - pack creates these builder images and controls the deletion of these builders as well. I'd like to use the core pack code to operate on a running image.

Re-implement buildpack parsing and downloading - We are afraid of drift in buildpack processing from pack itself. We would like a cnb user to be able to go from running pack to pushing that same code up to a platform without hitting differences in something as fundamental as defining which buildpacks and what order.

Questions

Can pack expose these with or without docker being required? If you had a tekton pipeline with a binary referencing pack running in a container with user code, could the pack lib be executed in the running image without needing docker? This would be useful for populating a /cnb/buildpacks volume that you could then carry on to the detector step.

[jromero]

If this was part of the Go lib interface, in your example for usage inside of something like tekton, the user of this library would be compiling a program in Go to use in this workflow ahead of time. This issue is not requesting that such utility function be exposed via a utility CLI or from the pack CLI executable correct?

A simplified example of the interface:

func DownloadBuildpack(buildpackURI string) (contents io.Reader, err error)

where:

• buildpackURI is implemented based on https://github.com/buildpacks/rfcs/blob/main/text/0037-buildpack-uris.md
• contents is a forward-only reader with the contents of the buildpacks in tar format

[jabrown85]

Correct, not asking for a CLI executable or utility CLI.

The simplified example looks good. That would allow a binary referencing pack as a lib to get the benefit of parsing URIs without re-implementing it while still allowing the binary to do whatever they want with those buildpacks (put in /buildpacks or wherever the platform wants them).