Skip to content
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

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

adswa
Copy link
Contributor

@adswa adswa commented Jul 12, 2022

This adds parameters to set cfgtype, cfgarch, and template 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

adswa added 12 commits July 12, 2022 10:46
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
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
@@ -58,22 +65,40 @@ class BootstrapBuilder(Interface):
doc="""specify a builder dataset that contains a build environment
configuration""",
constraints=EnsureDataset() | EnsureNone()),
template=Parameter(
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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

@yarikoptic
Copy link

Should be moved to draft mode may be?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

All singularity build templates will be built with identical names
3 participants