RFC: Group additions to Builder order

[jkutner]

Readable

[hone]

Do we already use the terminology pre or post anywhere? What do you think of start/end or first/last?

[hone]

Can you put an example here? I wonder if we should scope this to simple use cases if we can't express it in the CLI.

[hone]

I assume that if you can't satisfy or the buildpack id doesn't exist it will fail?

[jromero]

If I recall correctly, there were some changes suggested for this RFC.

1. The removal of a before concept since there was no concrete example IIRC.
2. Changing after to something like depends-on essentially creating a dependency model.

Additional note: suggestions to move this to buildpack.toml were questioned given that package.toml already has an existing dependency model.

[dfreilich]

Would this mean deprecating from=builder?

As a side point, the motivation described doesn't really make it clear for me what's wrong with from=builder (other than it being undocumented), and how this would help. If you could clarify that in the RFC, that would definitely help me understand it a bit more

[jkutner]

@dfreilich yea, goodbye from=builder. I'll make that more clear (we've already started to do that in the code though https://github.com/buildpacks/pack/blob/main/internal/buildpack/locator_type.go#L61-L66)

[jromero]

Based on the changes made to this RFC, it seems like the scope can be minimized to only prepend and append buildpacks. If so, could this not already be done provided buildpack URIs?

As an example

...in project.toml:

[[build.buildpacks]]
url = "./my-pre-buildpack"

[[build.buildpacks]]
url = "urn:cnb:builder"

[[build.buildpacks]]
url = "./my-post-buildpack"

... in pack:

# pre
pack my-image -B my-builder -b ./my-buildpack/ -b urn:cnb:builder

# post
pack my-image -B my-builder -b urn:cnb:builder  -b ./my-buildpack/

[jkutner]

@jromero i think we should kill urn:cnb:builder too, but that's definitely an alternative.

[jromero]

@jromero i think we should kill urn:cnb:builder too, but that's definitely an alternative.

If it's due to the fact that it's not intuitive I agree. Otherwise, I think it serves its purpose.

I have some slight reservations about boxing ourselves to pre and post terminology instead of a more robust solution but not strong enough to stand in the way of this RFC.

[dfreilich]

Overall, I think that the change is net positive. I have some nits (to @hone's point, I'm not sure whether pre/post is more or less intuitive than start/end), but those are implementation details, and I'd rather discuss them on the PR to add this, then slow down the process here.

To my mind, while we do have a perfectly good way of doing it now (either --buildpack from=builder or --buildpack urn:cnb:builder), those aren't intuitive (even if they were documented), and having an explicit flag for users will definitely help them appreciate how they can adjust builders for their needs.

1 question: do you think that users should be able to specify multiple --pre or --post buildpacks? I think that it should be fine, and there's no reason to restrict them to just one, but I'd like to see that explicitly discussed.

[jkutner]

@jromero yea, i actually tend to favor things don't require new flag or new things to learn, but I have two concerns about from=builder/urn:cnb:builder:

• It's not intuitive
• They actually represent a set of buildpacks (not a single buildpack) which makes it an odd-fellow with other single buildpacks defined with the --buildpack flag.

I have some slight reservations about boxing ourselves to pre and post terminology instead of a more robust solution but not strong enough to stand in the way of this RFC.

@jromero I do share this concern, which is why I was hoping to capture the before/after stuff too (but I think omitting it is the right thing to do now). My hunch though, is that changes to the middle of a default order/group will use a distinct mechanism regardless (especially since overriding a buildpack in the group will be necessary). All that said, I feel comfortable that the pre/post solution will ultimately not interfere with any future solution, and actually is solving a different kind of problem.

1 question: do you think that users should be able to specify multiple --pre or --post buildpacks? I think that it should be fine, and there's no reason to restrict them to just one, but I'd like to see that explicitly discussed.

@dfreilich yea, I think they would work like the normal --buildpack option (in terms of being a list)

[jkutner]

@ekcasey @sclevine @nebhale PTAL

[sclevine]

FCP starting 2/10

[sclevine]

@ekcasey can you link the created issues?

[ekcasey]

@sclevine implementation is a noop. But sorry, I faked you out. I was going through this too quickly and forgot the project.toml is specified so core is not a noop. Creating the issue now.

[sclevine]

@jromero @jkutner do we need to create any platform / learning issues?

[jkutner]

@sclevine probably. at a minimum the project.toml docs