search

buildpacks / rfcs

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

Add prepare operation RFC, continued #238

Open david-caro opened 2 years ago

david-caro commented 2 years ago

This follows up on #202

Readable

Change Log

2022-11-18 (3bb05f8)

2022-02-22 (94e3180, d02754f)

2022-02-10 (8fc7a70)

2022-02-07 (99fc145)

buildpack-bot commented 2 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

(none)

natalieparellano commented 1 year ago

@jkutner @jabrown85 any thoughts on this?

jkutner commented 1 year ago

I'd love to see this move forward. Thanks for opening it

sambhav commented 1 year ago

In general one alternative I would to see reflected in this proposal and discussed is the the following interface -

preparer </path/to/lifecycle-config.toml>

where the lifecycle config is a viper config file that maps to the various lifecycle binary flags + env vars. (See https://github.com/spf13/viper#reading-config-files).

The preparer would take the above file and modify any of the inputs in the file and pass it back to the platform to be supplied to the lifecycle.

The above file would also need to include the platform API. This way the preparer becomes a part of the platform API and has a way of modifying all the inputs needed.

This can be used to implement all of the possible functionality we could ever want from a prepare stage and this interface would be forward-compatible as long as the preparer is compatible with a certain platform API.

Related https://github.com/buildpacks/rfcs/pull/128

Maybe it's going too much into implementation details, but standardizing lifecycle input parsing on viper would allow us to expose a consistent format to map lifecycle binary CLI args <> config file <> lifecycle env vars and define an order of precedence for them.

david-caro commented 1 year ago

In general one alternative I would to see reflected in this proposal and discussed is the the following interface -

preparer </path/to/lifecycle-config.toml>

where the lifecycle config is a viper config file that maps to the various lifecycle binary flags + env vars. (See https://github.com/spf13/viper#reading-config-files).

The preparer would take the above file and modify any of the inputs in the file and pass it back to the platform to be supplied to the lifecycle.

The above file would also need to include the platform API. This way the preparer becomes a part of the platform API and has a way of modifying all the inputs needed.

This can be used to implement all of the possible functionality we could ever want from a prepare stage and this interface would be forward-compatible as long as the preparer is compatible with a certain platform API.

Related #128

Maybe it's going too much into implementation details, but standardizing lifecycle input parsing on viper would allow us to expose a consistent format to map lifecycle binary CLI args <> config file <> lifecycle env vars and define an order of precedence for them.

As I understand, this would introduce a new configuration file (the lifecycle-config.toml) and an new configuration file parsing strategy.

(btw. I can absolutely add the option you requested to the doc, just let me know, I'm trying to discuss/understand the details)

natalieparellano commented 1 year ago

@david-caro were you still interested in moving this one forward?

david-caro commented 1 year ago

I am yes, though I'm quite busy lately, feel free to take over if you want to push it

natalieparellano commented 1 year ago

@david-caro sounds good, I'll move this into draft for now. We can move it out of draft when someone has the bandwidth to pick it up :)