diff options
| author | Massimiliano Culpo <massimiliano.culpo@gmail.com> | 2022-04-08 23:26:17 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-04-08 15:26:17 -0600 |
| commit | 23e85f4086e0fe4d885cf765d7d7684e2016f036 (patch) | |
| tree | cd587dee1791bffef6df257d8bd661d049de98f6 /bin/haspywin.py | |
| parent | dfff935f174e9767552c681e3907bab415db79d2 (diff) | |
| download | spack-23e85f4086e0fe4d885cf765d7d7684e2016f036.tar.gz spack-23e85f4086e0fe4d885cf765d7d7684e2016f036.tar.bz2 spack-23e85f4086e0fe4d885cf765d7d7684e2016f036.tar.xz spack-23e85f4086e0fe4d885cf765d7d7684e2016f036.zip | |
Environments: unify the spec objects on first concretization (#29948)
Currently environments are indexed by build hashes. When looking into this bug I noticed there is a disconnect between environments that are concretized in memory for the first time and environments that are read from a `spack.lock`. The issue is that specs read from a `spack.lock` don't have a full hash, since they are indexed by a build hash which is strictly coarser. They are also marked "final" as they are read from a file, so we can't compute additional hashes.
This bugfix PR makes "first concretization" equivalent to re-reading the specs from a corresponding `spack.lock`, and doing so unveiled a few tests were we were making wrong assumptions and relying on the fact that a `spack.lock` file was not there already.
* Add unit test
* Modify mpich to trigger jobs in pipelines
* Fix two failing unit tests
* Fix another full_hash vs. build_hash mismatch in tests
Diffstat (limited to 'bin/haspywin.py')
0 files changed, 0 insertions, 0 deletions