Setting variants per package version in package.yaml

101 views
Skip to first unread message

Rob Groner

unread,
Apr 28, 2021, 5:07:20 PM4/28/21
to Spack
I've added matlab to our spack.yaml file and it gets installed.  Of course, for the install, I have to provide the installation key, so I do that.

I've been finding lately that Spack appears to be creating 2 specs for matlab, however.  There's the spec for the matlab I put in spack.yaml, with the install key, and then it creates another spec because (I think) a different package has matlab as a dependency.  So instead of using the matlab I have installed, it attempts to install it again.  I noticed this because when looking through the concretization, I see matlab@R2020b key=<installation-key-here>, which if the default value for the variant.  Because that's not a valid key, that install interestingly doesn't fail, but it does produce a blank prefix directory that spack considers valid and uses as a dependency.

Sooo...I know I can just go through the spack.yaml file and fully spec out to use matlab with the installation key everywhere that matlab is a dependency....but geez, this key is long and that will make it veeeery cluttered.

Add to that the problem that we actually have 3 versions of matlab installed, so 3 different keys.

What I'm wondering is if I can specify the key in the packages.yaml.  That way I'm hoping Spack will not create the ghost-spec with the default invalid value, and I'll have all of the keys stored in one location.

I cannot find any documentation on defining variants for individual specs of a package, and my guesses have missed the mark.  Sooo...is there any way in the packages.yaml that I can specify a separate key variant value for matlab@R2019a, matlab@R2020b and matlab@R2021a?

Using spack v0.16.0 on RHEL7.

Thanks.

Rob Groner

unread,
Apr 29, 2021, 10:02:00 AM4/29/21
to Spack
So the  other odd thing about this is.....Spack is showing a matlab spec and using it for all dependencies...but it doesn't show it CREATING that spec when I concretize.

These 3 specs do correspond to the 3 matlab specs I have in the spack.yaml file (absurdly long key removed)

==> Concretized matlab@R2021a%g...@4.8.5 key=16657-<snip>
[+]  ipxjlgc  matlab@R2021a%g...@4.8.5 key=16657-<snip> arch=linux-rhel7-ivybridge

==> Concretized matlab@R2020b%g...@4.8.5 key=04340-<snip>
[+]  es5bfua  matlab@R2020b%g...@4.8.5 key=04340-<snip> arch=linux-rhel7-ivybridge

==> Concretized matlab@R2019b%g...@4.8.5 key=27839-<snip>
[+]  4je5t4a  matlab@R2019b%g...@4.8.5 key=27839-<snip> arch=linux-rhel7-ivybridge


But everywhere that a package has matlab as a dependency, it is using a different spec with the "default" key variant value.  And nowhere does it show it actually CREATING this matlab spec....it only appears as a dependency.

==> Concretized gams@28.2%g...@4.8.5+matlab
[+]  exzxmzn  gams@28.2%g...@4.8.5+matlab arch=linux-rhel7-ivybridge
[+]  muiwdyw      ^matlab@R2021a%g...@4.8.5 key=<insert key here> arch=linux-rhel7-ivybridge
Reply all
Reply to author
Forward
0 new messages