Skip to content

Variant Forwarding Proposal #2594

@citibeth

Description

@citibeth

Comments / criticisms appreciated. This is a first stab at it.

In this proposal, the Spack concretizer and package syntax will be upgraded to allow variants to be "forwarded" through the DAG. This can be thought of as, effectively, the Spack concretizer overwriting the DAG through the concretization process (sorry, I don't have a well thought out algorithm). Forwarding happesn before concretization.

In general... if A->B and we want to forward the x variant from A to B, then this would be accomplished by the following transformations:

A+x ==> A+x^B+x
A~x ==> A~x^B~x
A ==> A^B

In the last case, B will receive whatever value for x it "naturally" would have had without variant forwarding. It would be an error to forward x to B if B does not have variant x to begin with.

Variants can also be forwarded transitively. If A->B->C, and we "transitively forward" variant x from A to B, then C will also receive x --- even if B does not use the variant x.

Although it is possible in theory to forward any variant in A to any variant in B, this will not be permitted: variant forwarding must be between variants of the same name.

Variant forwarding can be specified in the package.py files. For example:

class A(Package):
    variant('x')
    depends_on('B', forward=('x',))     # Regular forwarding
    depends_on('C', forward=('x*',))   # Forward transitively

We can also forward variants from packages.yaml. For example:

    icebin:
        version: [develop]
        variants: +*gridgen+python~**everytrace

In this case, +*gridgen sets the gridgen variant and then forwards it to all dependencies; ~**everytrace clears the everytrace variant and then forwards it transitively to all dependencies.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions