search

buildpacks / rfcs

RFCs for Cloud Native Buildpacks
Apache License 2.0
57 stars 71 forks source link

RFC: Remove Stacks & Mixins #172

Closed sclevine closed 3 years ago

sclevine commented 3 years ago

Readable.

This proposal is part of a larger initiative to reduce complexity originally outlined in https://github.com/buildpacks/rfcs/pull/167

sclevine commented 3 years ago

Idea I'd like feedback on: what if we dropped the packages list from both buildpack.toml and detect, at least for now? Builder authors could be responsible for reading buildpack documentation and installing any extra packages. We could re-introduce this functionality, if necessary, as part of #174.

dmikusa commented 3 years ago

Idea I'd like feedback on: what if we dropped the packages list from both buildpack.toml and detect, at least for now? Builder authors could be responsible for reading buildpack documentation and installing any extra packages. We could re-introduce this functionality, if necessary, as part of #174.

I like that this change makes things simpler and I'm not sure I would have used this packages list often.

I do think it would have been helpful for the Paketo PHP buildpack, given that PHP and its many C-based extensions have lots of library requirements. At the same time, it would have been very tedious to spell out all of the packages to really take advantage of this feature (same with mixins). I would also be OK with having a builder specific for PHP, where the requirements are spelled out, especially the way that #173 is shaping up.

buildpack-bot commented 3 years ago

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

sclevine commented 3 years ago

All outstanding feedback addressed. Looking for additional feedback or approval @buildpacks/core-team

ekcasey commented 3 years ago

FCP closing September 1

sclevine commented 3 years ago

@hone addressed in RFC, let me know if you have more questions/concerns

hone commented 3 years ago

Is there anything else outstanding to be resolved on this?

hone commented 3 years ago

@sclevine can you add to unresolved so I can merge this:

Are we planning to export multiple images? Or is this a list of "potential" targets?

hone commented 3 years ago

@ekcasey kindly requests when this gets merged, @buildpacks/platform-maintainers starts with a sub-team RFC to discuss the UX around removing stacks, etc.

sclevine commented 3 years ago

@hone added, ready to merge

hone commented 3 years ago

I think the bot may be broken. :( @buildpacks/implementation-maintainers @buildpacks/platform-maintainers are there any issues that need to be opened before I merge this in?

jromero commented 3 years ago

I think the bot may be broken. :( @buildpacks/implementation-maintainers @buildpacks/platform-maintainers are there any issues that need to be opened before I merge this in?

It's not broken. The issues only get created when this gets merged via merge-rfc.sh.

EDIT: You can see the list of queued issues here: https://github.com/buildpacks/rfcs/pull/172#issuecomment-897617181

edmorley commented 2 years ago

The current buildpack API spec includes CNB_STACK_ID being set in the environment of buildpack detect/build: https://github.com/buildpacks/spec/blob/buildpack/v0.8/buildpack.md#provided-by-the-platform

That env var is commonly used by buildpacks when determining which binary to download/install for those that are compiled for specific OSes/OS versions.

This RFC doesn't mention what happens to that env var. Is it now considered deprecated too? Or are only the buildpack.toml stacks parts being deprecated?

If CNB_STACK_ID is being deprecated, could the RFC be updated to clarify this + explain what buildpacks should now use instead? (I would presume they now need to construct the stack name/version/... from the new CNB_TARGET_* env vars?)