design #3
design #3
Conversation
There was a problem hiding this comment.
This is really great. Twoliter's purpose is nice and crisp. I have a few minor nits and comments inline.
General thoughts:
- The document switches between being written as a narrative and other times it uses specification wording ("Maintainers must...", "Twoliter will..."). Personally, I don't know if the specification wording is helpful, regardless, it might be good to go in a single direction for the entire document or at least make a section internally consistent.
- A section that describes an end-to-end concrete example would be helpful. Describe a kit, show how it's used in a twoliter project, how you build it, etc.
There was a problem hiding this comment.
This is really great. Twoliter's purpose is nice and crisp. I have a few minor nits and comments inline.
General thoughts:
- The document switches between being written as a narrative and other times it uses specification wording ("Maintainers must...", "Twoliter will..."). Personally, I don't know if the specification wording is helpful, regardless, it might be good to go in a single direction for the entire document or at least make a section internally consistent.
- A section that describes an end-to-end concrete example would be helpful. Describe a kit, show how it's used in a twoliter project, how you build it, etc.
webern
force-pushed
the
design
branch
2 times, most recently
from
11d616e
to
da356b0
Compare
|
This includes all the easy fixes, most of the related comments have been marked as resolved. |
|
I had missed a few of Ben's quick fixes. |
|
Add a requirement that makes it more clear that maintainers can opt out of certain Bottlerocket features by choosing not to install the relevant packages. No change was needed to the design. |
|
Print |
|
|
This is pretty serviceable and I would like to get it merged and get going on issue creation. I think we can safely assume that the design will evolve but we have a pretty good picture of what we are building. The diff of everything I've done since everyone reviewed it is: https://github.com/bottlerocket-os/twoliter/compare/da356b0..d62870ea1907b2555040cc421cb8c609e5c3f9ea |
|
Addresses all known edit requests. |
| ```toml | ||
| [dependencies] | ||
| # implicitly gets modified to append the target arch during dependency resolution | ||
| # results in public.ecr.aws/bottlerocket/bottlerocket-sdk-x86_64:v0.50.0 | ||
| bottlerocket-sdk = "0.50.0" | ||
| ``` | ||
|
|
||
| At this point Twoliter will build a package that represents the maintainers top level dependencies. | ||
|
|
||
| ```toml | ||
| [dependencies] | ||
| bottlerocket-sdk = "=0.50.0" | ||
| bottlerocket-core-kit = "=1.1.15" | ||
|
|
||
| # explicitly set to some other prefix | ||
| third-party-kit = { source = "some.registry/prefix", version = "=0.10.0" } |
There was a problem hiding this comment.
What file does this go into? The top-level Twoliter.toml?
One idea is for that file to just have an unversioned list of kits (and maybe sources), like:
kits = [
"bottlerocket-core-kit",
"bottlerocket-aws-kit",
"bottlerocket-k8s-kit",
{ name = "my-other-kit", source = "some.registry/prefix" },
]
And then twoliter add / twoliter update would rewrite Twoliter.lock with the latest versions that satisfy their mutual dependencies.
[sdk]
name = "bottlerocket-sdk"
version = "0.100.0"
source = "public.ecr.aws/bottlerocket"
[[kit]]
name = "bottlerocket-core-kit"
version = "0.50.0"
source = "public.ecr.aws/bottlerocket"
[[kit]]
name = "bottlerocket-aws-kit"
version = "0.1.0"
source = "public.ecr.aws/bottlerocket"
[[kit]]
name = "bottlerocket-k8s-kit"
version = "0.2.0"
source = "public.ecr.aws/bottlerocket"
[[kit]]
name = "my-other-kit"
version = "0.0.1"
source = "some.registry/prefix"
A project like this might end up seeing many, relatively independent builds of each kit if their only common dependency is the SDK and if the kit projects move faster than the SDK (which is likely). Trying to keep track of that by hand would be maddening.
I'm OK with not knowing how the dependency solver will be implemented, but I want to make sure the design reflects the intended maintainer experience.
There was a problem hiding this comment.
What file does this go into? The top-level Twoliter.toml?
No, I think kit dependencies are done in variant/Cargo.toml. What I was showing here is an example of how the resolver might use cargo to generate crates that will enforce the versioning of kits.
|
Capture some of the things that have changed about the design during discussions. Ben's comments. |
| ```toml | ||
| [dependencies] | ||
| # implicitly gets modified to append the target arch during dependency resolution | ||
| # results in public.ecr.aws/bottlerocket/bottlerocket-sdk-x86_64:v0.50.0 | ||
| bottlerocket-sdk = "0.50.0" | ||
| ``` | ||
|
|
||
| At this point Twoliter will build a package that represents the maintainers top level dependencies. | ||
|
|
||
| ```toml | ||
| [dependencies] | ||
| bottlerocket-sdk = "=0.50.0" | ||
| bottlerocket-core-kit = "=1.1.15" | ||
|
|
||
| # explicitly set to some other prefix | ||
| third-party-kit = { source = "some.registry/prefix", version = "=0.10.0" } |
There was a problem hiding this comment.
What file does this go into? The top-level Twoliter.toml?
No, I think kit dependencies are done in variant/Cargo.toml. What I was showing here is an example of how the resolver might use cargo to generate crates that will enforce the versioning of kits.
|
Small fixes. @bcressey this is ready for review again. |
Adds a design doc describing the Twoliter build tool.
Issue #, if available:
Closes #1
Related to bottlerocket-os/bottlerocket#2669
Description of changes:
Adds a document describing the design of twoliter.
TODO
dnf list installedoutput forhttps://github.com/bottlerocket-os/twoliter/pull/3/files#r1195749281https://github.com/bottlerocket-os/twoliter/pull/3/files#r1195553253https://github.com/bottlerocket-os/twoliter/pull/3/files/#r1195738646https://github.com/bottlerocket-os/twoliter/pull/3/files/#r1195739587(See refine kit and artifact signing design #5)By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.