* New version: py-lz4 3.1.3; use external lz4 instead of bundled one
* Update var/spack/repos/builtin/packages/py-lz4/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Changes from review
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Add spack package py-ytopt-team-ytopt and required dependencies.
* Removed old ytop package.
* Added author as maintainer.
* Fix style.
* Update var/spack/repos/builtin/packages/py-config-space/package.py
Update python dependency to 3.7
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-config-space/package.py
Remove run dependency from py-cython.
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-config-space/package.py
Added run dependency type for py-pyparsing.
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Updated description of py-dh-scikit-optimize.
* Source py-dh-scikit-optimize from PyPI.
* Added latest py-dh-scikit-optimize version.
* Made plots option False by default for py-dh-scikit-optimize.
* Removed 0.9.4 as it needs additional dependencies.
* Added version dependencies.
* Added missing py-joblib dependencies.
* Added run dependency type.
* Added python 2.7+ as supported for py-pyaml.
* Change py-config-space to py-configspace.
* Added dependency on python 3.6+.
* Fix py-configspace package naming.
* Changed py-autotune to py-ytopt-autotune.
* Update var/spack/repos/builtin/packages/py-pyaml/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Added debug variant with py-ray dependency.
* Added missing py-mpi4py missing dependency.
* Removed erroneous variant.
* Added debug variant to py-ray.
* Fix indentation.
* Removed debug variant of py-ray.
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Noting that missing numeric_limits was the cause of the compile issues
with gcc-11, I tested adding -include limits fixing @5.9:5.14%gcc@11.
Therefore, we can replace the conflicts('%gcc@11:', when='@5.9:5.14').
Co-authored-by: Bernhard Kaindl <bernhard.kaindl@ait.ac.at>
* Prevent additional properties to be in the answer set when reusing specs
fixes#27237
The mechanism to reuse concrete specs relies on imposing
the set of constraints stemming from the concrete spec
being reused.
We also need to prevent that other constraints get added
to this set.
See #25249 and https://github.com/spack/spack/pull/27159#issuecomment-958163679.
This adds `spack load --list` as an alias for `spack find --loaded`. The new command is
not as powerful as `spack find --loaded`, as you can't combine it with all the queries or
formats that `spack find` provides. However, it is more intuitively located in the command
structure in that it appears in the output of `spack load --help`.
The idea here is that people can use `spack load --list` for simple stuff but fall back to
`spack find --loaded` if they need more.
- add help to `spack load --list` that references `spack find`
- factor some parts of `spack find` out to be called from `spack load`
- add shell tests
- update docs
Co-authored-by: Peter Josef Scheibel <scheibel1@llnl.gov>
Co-authored-by: Richarda Butler <39577672+RikkiButler20@users.noreply.github.com>
Reformulate variant rules so that we minimize both
1. The number of non-default values being used
2. The number of default values not-being used
This is crucial for MV variants where we may have
more than one default value
In our tests, we use concrete specs generated from mock packages,
which *only* occur as inputs to the solver. This fixes two problems:
1. We weren't previously adding facts to encode the necessary
`depends_on()` relationships, and specs were unsatisfiable on
reachability.
2. Our hash lookup for reconstructing the DAG does not
consider that a hash may have come from the inputs.
Concrete specs that are already installed or that come from a buildcache
may have compilers and variant settings that we do not recognize, but that
shouldn't prevent reuse (at least not until we have a more detailed compiler
model).
- [x] make sure compiler and variant consistency rules only apply to
built specs
- [x] don't validate concrete specs on input, either -- they're concrete
and we shouldn't apply today's rules to yesterday's build
In switching to hash facts for concrete specs, we lost the transitive facts
from dependencies. This was fine for solves, because they were implied by
the imposed constraints from every hash. However, for `spack diff`, we want
to see what the hashes mean, so we need another mode for `spec_clauses()` to
show that.
This adds a `expand_hashes` argument to `spec_clauses()` that allows us to
output *both* the hashes and their implications on dependencies. We use
this mode in `spack diff`.
- [x] Get rid of forgotten maximize directive.
- [x] Simplify variant handling
- [x] Fix bug in treatment of defaults on externals (don't count
non-default variants on externals against them)
Variants in concrete specs are "always" correct -- or at least we assume
them to be b/c they were concretized before. Their variants need not match
the current version of the package.
