-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The build plan should lose entries as they are provided by each /bin/build #24
Comments
An example would help (as usual). |
Here's a simple example that ignores the Detect Phasemy.buildpack.one:
my.buildpack.two:
Build PhaseAssuming my.buildpack.two is requesting my-dep-two from my.buildpack.one, and the other requested layers are provided by the buildpack requesting them. my.buildpack.one:
my.buildpack.two:
|
How is it doing that? Surely |
This proposal is problematic as there is not a a 1:1 correspondence between the entries in the build plan and the layers put down on disk. For example, when a buildpack requests This feels like an attempt to tighten the contract to prevent what will be a rare occurrence when it should just be clearly stated the buildpack groups (which are quite lightweight, so you can have many of them) should be created in such a way as to remove the possibility of dependency provisioning collision. Tightening the contract here, without any evidence that this is a wide-spread problem is reducing our ability to innovate and create new patterns that do not already exist. |
Buildpacks would request all three of those things instead of just
This is covered by: "Have a separate, special build plan notation for dependencies provided in the app directory."
That buildpack would request
Without this feature, it would be difficult to implement manifest dependency overrides, which are a current feature of the CF buildpacks. Additionally, the current implementation puts the onus on operators and developers to know about every layer name their chosen buildpacks provide. That said, I think Option B satisfies all of your constraints and would solve the problem without tightening the contract. |
I don’t believe that it should be a requirement that buildpacks requesting a dependency have internal knowledge of all of the dependencies that another buildpack will provide. For example, a riff buildpack only needs to request that a JRE be present. It should *not * need to know that some JRE providers will provide an additional memory calculator and jvmkiller whereas other JRE providers will not. Making all provided dependencies explicit in the build plan creates a very tight coupling where two buildpacks essentially can only depend on one another with deep internal knowledge rather than allowing buildpacks be polymorphic dependency providers that can transparently substitute in for one another. Also the requirement for both Option A and B
is problematic as some build plan entries are never meant to be consumed. At the moment |
What if, at least for now, we condense this proposal down to: A buildpack may erase any number of dependencies from the build plan in I would still prefer a tighter contract, because I think the current contract is somewhat difficult for new buildpack authors to reason about, but this would solve the problem that I'm trying to solve. It would also be an additive, non-breaking change. |
It's news to me that a build plan contains dependencies. Is that explicit? The first reference I can find to "dependency" is in the "build" phase, and it's a bit vague there (doesn't mention anything to do with the build plan). |
@sclevine Definitely a better choice. How would such a behavior be implemented since |
@dsyer You've hit upon one of the assumptions I was arguing against here. The build plan was originally conceived as a way to create an inventory of dependencies contributed by buildpacks, conveniently allowing tools to observe and report on them. However, the design is much more generic than that, acting as a whiteboard pattern that both communicates more than just dependencies and doesn't necessary report all dependencies at the same time. My vote is for this looser design to continue (it's been very helpful for my buildpacks) rather than restricting it to the original idea. |
I'm ready to see a spec PR for the change. |
Note: This proposal has been edited. Comments below it may be outdated. See the edit history for previous versions.
If a buildpack’s
/bin/build
provides a dependency specified in the build plan, then the buildpack should be able to remove that build plan entry so that it is not provided to the next buildpack’s/bin/build
. Otherwise, the same dependency may unintentionally be provided multiple times.Advantages
provider
key unnecessary in almost all cases./bin/build
and/bin/detect
interfaces much more consistent.Interface Changes
Modify the input and output interface for detection:
Executable:
/bin/detect <platform[A]>
, Working Dir:<app[AR]>
/dev/stdin
<platform>/env/
<platform>/plan/
<platform>/#
/dev/stdout
/dev/stderr
To contribute plan entries, buildpacks write entries to
<platform>/plan/<name>
. Entries do not need to have a top-level<name>
key.Modify the input interface for build:
Executable:
/bin/build <platform[A]> <cache[EC]> <launch[EI]>
, Working Dir:<app[AI]>
/dev/stdin
<platform>/env/
<platform>/plan/
<platform>/#
To remove plan entries, buildpacks write empty files to
<platform>/plan/<name>
. Entries do not need to have a top-level<name>
key. This file could be metadata about the exact dependency provided, e.g., checksums not available during build.The text was updated successfully, but these errors were encountered: