- Variant concretization is tricky:
- During concretization, a spec without variants (e.g., mpich) means
"don't care". So, Spec('mpich').satisfies('mpich+debug') is true
because it *could* still be built that way.
- After concretization, a spec without a particular variant means
"don't know", as that wasn't part of the spec, so the opposite
relationship is true. Assume 'spec' is already installed:
spec.satisfies('mpich+debug')
this is false beacuse the `debug` variant didn't exist when spec
was built, so we can't satisfy the explicit request for +debug.
- Variants are now declarable in packages using the variant() directive.
- Variants are checked - you can't just ask for a random variant, it has to be declared.
- conditional logic (@when, if, '+debug' in spec, etc.) still required in package to
implement variant.
Suppress python stack trace on build error UNLESS in debug mode (spack -d).
Now spack shows errors with a single red arrow, and it's easier to find the actual build output.
spack activate
- now activates dependency extensions
- ensures dependencies are activated in the python installation.
- -f/--force option still allows the old activate behavior.
spack deactivate
- checks for dependents before deactivating (like uninstall)
- deactivate -a/--all <extension> will deactviate a package and ALL
of its dependency extensions.
- deactivate -a/--all <extendee> activates all extensions of <extendee>
e.g.: spack deactivate -a python
- deactivate -f/--force option allows removing regardless of dependents.
- deactivate -f can be run EVEN if a package is not activated.
- allows for clenup of activations gone wrong.
- Real bottleneck is calling normalize() for every spec when we read it.
- Need to store graph information in spec files to avoid the need for this.
- Also, normalizing old specs isn't always possible, so we need to do this anyway.
