Configure builder args - #104
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
| doc="""specify a builder dataset that contains a build environment | ||
| configuration""", | ||
| constraints=EnsureDataset() | EnsureNone()), | ||
| template=Parameter( |
There was a problem hiding this comment.
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.
Or, as a different angle: With could turn
cfgtypeinto 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.
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.
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-buildertakes 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? |
3 participants
This adds parameters to set
cfgtype,cfgarch, andtemplatewhere 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