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

Allow setting default variants #2644

Merged
merged 1 commit into from
Dec 30, 2016

Conversation

michaelkuhn
Copy link
Member

Currently, it seems to not be possible to set default variants for all packages like this:

packages:
  all:
    variants: +X

This PR allows doing so.

@adamjstewart
Copy link
Member

Whoo! This should fix #2165.

@adamjstewart
Copy link
Member

Might also want to document this.

@michaelkuhn
Copy link
Member Author

The documentation actually states this, which made me think that this would/should be supported anyway:

Each packages.yaml file begins with the string packages: and package names are specified on the next level. The special string all applies settings to each package. Underneath each package name is one or more components: compiler, variants, version, or providers. Each component has an ordered list of spec constraints, with earlier entries in the list being preferred over later entries.

Of course, I could add something more explicit.

@citibeth
Copy link
Member

Not all packages have a +X variant. So this PR should be specific about how all@+X affects:

  1. Packages with variant('X', default=True)
  2. Packages with variant('X', default=False)
  3. Packages with variant('X')
  4. Packages without any variant named X

My larger concern is that this might be jumping the gun on our discussion of variant forwarding vs. universal variants. This features seems akin, somewhat, to universal variants. I think it would be best if we can nail down a coherent design before going ahead with features here and there.

@@ -154,7 +154,10 @@ def spec_has_preferred_provider(self, pkgname, provider_str):

def spec_preferred_variants(self, pkgname):
"""Return a VariantMap of preferred variants and their values"""
variants = self.preferred.get(pkgname, {}).get('variants', '')
for pkg in (pkgname, 'all'):
variants = self.preferred.get(pkg, {}).get('variants', '')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would not this add default variant to a package which does not have it? Does it make its hash change? Can you please test it (take any two dependent packages where root has some variant and a dependency does not)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is working correctly as far as I can tell. I have added a dummy variant to m4 and built it with and without an appropriate packages.yaml. The hash of the only dependency does not change and both m4 variants use the same dependency.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great, thanks for checking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Suraia: This will fail if the package doesn't support the particular global variant. It sounds like it worked for you because you added a variant to m4, but it would be nice to prefer all: +debug even when some packages don't have debug. I'll put how to fix it below.

@michaelkuhn
Copy link
Member Author

@citibeth For me, this is not really about the X variant. Maybe someone wants to disable MPI variants globally or just not specify each package individually for a common variant. This only fixes something that should have been working all along in my opinion.

@citibeth
Copy link
Member

citibeth commented Dec 20, 2016 via email

Copy link
Member

@tgamblin tgamblin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I believe this will still fail if a package doesn't support a variant.

@@ -154,7 +154,10 @@ def spec_has_preferred_provider(self, pkgname, provider_str):

def spec_preferred_variants(self, pkgname):
"""Return a VariantMap of preferred variants and their values"""
variants = self.preferred.get(pkgname, {}).get('variants', '')
for pkg in (pkgname, 'all'):
variants = self.preferred.get(pkg, {}).get('variants', '')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Suraia: This will fail if the package doesn't support the particular global variant. It sounds like it worked for you because you added a variant to m4, but it would be nice to prefer all: +debug even when some packages don't have debug. I'll put how to fix it below.

for pkg in (pkgname, 'all'):
variants = self.preferred.get(pkg, {}).get('variants', '')
if variants:
break
if not isinstance(variants, basestring):
variants = " ".join(variants)
return spack.spec.Spec("%s %s" % (pkgname, variants)).variants
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you change this line to look like this:

s = spack.spec.Spec("%s %s" % (pkgname, variants))
pkg = spack.repo.get(pkgname)
return dict((v.name, v) for v in s.variants if v.name in pkg.variants)

@michaelkuhn
Copy link
Member Author

@tgamblin I have actually built a few packages that did not have variants that were specified globally and those did not fail for me. I see your point, though, and have pushed an updated version.

@tgamblin tgamblin merged commit a42f340 into spack:develop Dec 30, 2016
@adamjstewart adamjstewart mentioned this pull request Jan 9, 2017
@citibeth citibeth mentioned this pull request Feb 10, 2017
@michaelkuhn michaelkuhn deleted the allow-setting-default-variants branch February 22, 2017 19:22
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.

None yet

5 participants