Conversation
Signed-off-by: Joe Kutner <jpkutner@gmail.com> wip wip wip wip
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Signed-off-by: Terence Lee <hone02@gmail.com>
Signed-off-by: Terence Lee <hone02@gmail.com>
Signed-off-by: Terence Lee <hone02@gmail.com>
| id = "<buildpack ID (required)>" | ||
| version = "<buildpack version (optional default=latest)>" | ||
| optional = "<bool (optional default=false)>" | ||
| uri = "<url or path to the buildpack (optional default=urn:buildpack:<id>)" |
There was a problem hiding this comment.
Should this be an image ref to a buildpackage? Otherwise, I think we'd need a centralized buildpack registry to resolve all the dependent IDs in the downloaded artifact.
There was a problem hiding this comment.
Should this be an image ref to a buildpackage?
can you elaborate on this? Maybe that's changed now that distribution spec is done?
Otherwise, I think we'd need a centralized buildpack registry to resolve all the dependent IDs in the downloaded artifact.
Why centralized? I imagine that the platform would have a default registry, but maybe that can be overriden.
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - Name the file `project.toml` and keep the schema described herein. |
There was a problem hiding this comment.
I'm willing to concede and use project.toml as the name, but I'd like to see if we can keep the schema the same as buildpack.toml. I think the [project] table has fields are are useful in both apps and buildpacks, and I'd like to see it added in both places. The [image] table might not make sense on a buildpack (that table was meant to capture things that are specific to a repo you run buildpacks against).
However... maybe some of this changes if you can run buildpacks on a buildpack to produce a buildpackage 🤔
There was a problem hiding this comment.
maybe some of this changes if you can run buildpacks on a buildpack to produce a buildpackage
I think this is the disconnect. I have trouble imagining how a buildpack could be built with another buildpack, or otherwise act like an app. Let's chat about this during the WG meeting.
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - Is `path` overriding `uri` and other elements confusing? Should these be the same key, and the execution environment figures out how to handle (i.e. `/user/local` versus `https://example.com`). | ||
| - Do multiple `[[images]]` result in multiple builds, or are the images derived from a single build? |
There was a problem hiding this comment.
Thinking about this, it would be really easy to create multiple images in a single build by allowing buildpacks to add image names to layer metadata.
text/0000-project-descriptor.md
Outdated
| name = "<string>" | ||
| version = "<string>" | ||
| authors = ["<string>"] | ||
| documentation = "<string>" |
There was a problem hiding this comment.
yea, probably makes sense for docs to be a URI. will update
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
jkutner
force-pushed
the
project-descriptor
branch
from
f747539 to
0cc209e
Compare
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
sclevine
left a comment
sclevine
left a comment
There was a problem hiding this comment.
My biggest worry about this proposal is inline buildpack support. I think it's confusing to have the buildpack fields inside of project.toml, and I don't understand the motivation doing that vs. having a separate buildpack.toml. Additionally, limiting project.toml to a single inline buildpack leads to unusual workflows. For example, your inline buildpack can be a concrete buildpack. But if you want that buildpack to use another buildpack, it needs to become a meta-buildpack. But then you can't specify a concrete inline buildpack anymore.
I'm also a bit worried that this creates three different ways of specifying the buildpacks that apply to an app:
project.buildpacksimages.buildpacksorder(with the inline buildpack in one of the two above)
Maybe order doesn't make sense in this context?
| id = "<string>" | ||
| name = "<string>" | ||
| version = "<string>" | ||
| authors = ["<string>"] |
There was a problem hiding this comment.
Should this be more structured? E.g.,
[[authors]]
name = "Bob"
email = "bob@example.com"
Not suggesting it should, just wondering.
There was a problem hiding this comment.
i wondered the same, but it could be "Bob <bob@example.com>". i don't have strong feelings either way.
| source = "<url>" | ||
| include = ["<string>"] | ||
| exclude = ["<string>"] | ||
| publish = "<boolean>" |
There was a problem hiding this comment.
I'm assuming registry-specific fields aren't going to make it into the spec until a registry exists. Correct?
(Also, I'm assuming the bool is not a string.)
| optional = "<boolean>" # question: is there actually a use case for this? | ||
| uri = "<url or path>" | ||
|
|
||
| [buildpack] # used for inline buildpack |
There was a problem hiding this comment.
Feels a bit weird that the inline buildpack can have a different version than the project, but I'm not sure if there's a nice solution to this.
There was a problem hiding this comment.
Also, how you do specify multiple inline buildpacks?
There was a problem hiding this comment.
I'm not sure we need to support that use case. What's the value of decomposing if their already inline/in-repo?
| [[order]] # used for inline buildpack | ||
| # matches buildpack.toml | ||
|
|
||
| [[stacks]] # allowed, but ignored for inline buildpack |
There was a problem hiding this comment.
How does an inline buildpack specify stacks? Is it assumed to be compatible with all listed stacks? What if the inline buildpack is compatible with one of the images stacks but not another?
| stack = "<string>" | ||
|
|
||
| [images.launch.env] | ||
| key1 = "<string>" |
There was a problem hiding this comment.
I'd prefer:
name = "<string>"
value = "<string>"
If only to match the k8s convention.
| [[project.buildpacks]] | ||
| id = "<string>" # may reference [buildpack.id] in this file | ||
| version = "<string>" | ||
| optional = "<boolean>" # question: is there actually a use case for this? |
There was a problem hiding this comment.
I think we should leave optional out. Unless we allow full order semantics, optional provides incomplete functionality anyways. And I think this list should be something that the user is explicitly deciding.
|
|
||
| [[project.buildpacks]] | ||
| id = "<string>" # may reference [buildpack.id] in this file | ||
| version = "<string>" |
There was a problem hiding this comment.
Assuming version is optional here?
| exclude = ["<string>"] | ||
| publish = "<boolean>" | ||
|
|
||
| [[project.buildpacks]] |
There was a problem hiding this comment.
How would you feel about dropping this list and forcing users to use [[images]]?
|
Closing in favor of #25. The inline buildpack (and probably scriptless buildpack) will be reborn in a forthcoming RFC |
3 participants
Readable