-
Notifications
You must be signed in to change notification settings - Fork 5
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
Configure builder args #104
base: main
Are you sure you want to change the base?
Conversation
This is a prerequisite to make architecture and environment type actually configurable once several different ways exist. The new parameters default values preserve current behavior
… into configure-builder-args
…d environment specification
This allows to have builder datasets with multiple environments created for the same arch and cfgtype, but with different templates, and allows to specify specific environments when bootstrapping the environments or building packages with them
…ent and build command assembly
… into configure-builder-args
@@ -58,22 +65,40 @@ class BootstrapBuilder(Interface): | |||
doc="""specify a builder dataset that contains a build environment | |||
configuration""", | |||
constraints=EnsureDataset() | EnsureNone()), | |||
template=Parameter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe flavor
is a more fitting name?
Or, as a different angle: With could turn cfgtype
into a proper mode switch to select the to-be-employed technology, but no longer have any implications on the "template" filename (for the recipe at least).
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, as a different angle: With could turn
cfgtype
into a proper mode switch to select the to-be-employed technology, but no longer have any implications on the "template" filename (for the recipe at least).
I think it sounds nice, but how would it work? Do I understand correctly that cfgtype wouldn't be part of the recipe names, and the mode switch would only influence the build cmd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, something like that. One option to label the environment, and one option to select the right builder for that environment.
That being said, I have likely not thought this through as much as you did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on. Now I got it. template
refers to the instantiated "template". This is what threw me off. What about this for a terminology:
- template: this is what
configure-builder
takes as input - recipe: this is what
configure-builder
's output is called (the instantiated template with a placeholder fulfilled)
So when bootstrap-builder
needs to run, we can give it a recipe filename and either
- decode the handler (e.g. singularity), and flavor from the filename by enshrining a syntax for it
- take the recipe name verbatim/uninterpreted and require specification of the handler
Both approaches would be fine from my POV
Should be moved to draft mode may be? |
This adds parameters to set
cfgtype
,cfgarch
, andtemplate
where applicable to exert more fine-grained control over how environments are named or which environments are used (fixes interal TODOs) . It also switches internal naming and name lookup for environments and images to include a template specification. This fixes #100, and allows to have more than one builder per cfgtype, e.g., also for multiple templates per builder dataset.For now it sits on top of #97