Enable and constrain reuse for GitVersion installations by psakievich · Pull Request #43859 · spack/spack

psakievich · 2024-04-26T04:23:27Z

TLDR:

This PR fixes two issues:

Spack's concretizer failed when a GitVersion had a prior install with the same version
Fixing 1) exposed that the concretizer's re-use would pick a GitVersion over StandardVersions if they were installed sooner and met the satisfies criteria. We want it to only pick GitVersions when the version is exactly equal.

Original Post

Currently the concretizer fails if you reuse a git ref version that has already been installed but modify the spec at all.

See #38484 for futher diagnosis

The issue here is that since there is no established provenance for these versions the highest weight they are currently assigned is that of prior install. Re-use checks then fail because the weight of the version is identical to the solver.

Ironically, these versions are given the highest weights possible when specified on the CLI for the first time. They should only appear in a DAG if they are an exact match or if the user specifies them at the CLI. Therefore it makes sense to preserve their higher ordering.

Getting this right is critical to moving all branch based versions to a pinned git-ref in the future.

Currently the concretizer fails if you reuse a git ref version that has already been installed but modify the spec at all. See #38484 for futher diagnosis The issue here is that since there is no established provenance for these versions the highest weight they are currently assigned is that of prior install. Re-use checks then fail because the weight of the version is identical to the solver. Ironically, these versions are given the highest weights possible when specified on the CLI for the first time. They should only appear in a DAG if they are an exact match or if the user specifies them at the CLI. Therefore it makes sense to preserve their higher ordering. Getting this right is critical to moving all branch based versions to a pinned git-ref in the future.

psakievich · 2024-04-26T04:26:59Z

@spackbot fix style

spackbot-app · 2024-04-26T04:27:01Z

Let me see if I can fix that for you!

spackbot-app · 2024-04-26T04:28:21Z

I was able to run spack style --fix for you!

spack style --fix

==> Running style checks on spack
  selected: isort, black, flake8, mypy
==> Modified files
  lib/spack/spack/solver/asp.py
==> Running isort checks
  isort checks were clean
==> Running black checks
reformatted lib/spack/spack/solver/asp.py
All done! ✨ 🍰 ✨
1 file reformatted.
  black checks were clean
==> Running flake8 checks
  flake8 checks were clean
==> Running mypy checks
lib/spack/spack/version/version_types.py:145: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:452: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:481: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
Found 3 errors in 1 file (checked 622 source files)
  mypy found errors

Keep in mind that I cannot fix your flake8 or mypy errors, so if you have any you'll need to fix them and update the pull request. If I was able to push to your branch, if you make further changes you will need to pull from your updated branch before pushing again.

I've updated the branch with style fixes.

psakievich · 2024-04-26T04:36:11Z

Interestingly this PR is currently giving the wrong reuse results for a standard case though:

$ spack solve zlib-ng
==> Best of 4 considered solutions.
==> Optimization Criteria:
  Priority  Criterion                                            Installed  ToBuild
  1         number of packages to build (vs. reuse)                      -        0
  2         number of nodes from the same package                        -        0
  3         requirement weight                                           0        0
  4         deprecated versions used                                     0        0
  5         version weight                                               5        0
  6         number of non-default variants (roots)                       0        0
  7         preferred providers for roots                                0        0
  8         default values of variants not being used (roots)            0        0
  9         number of non-default variants (non-roots)                   0        0
  10        preferred providers (non-roots)                              0        0
  11        compiler mismatches that are not from CLI                    0        0
  12        compiler mismatches that are not from CLI                    0        0
  13        non-preferred OS's                                           0        0
  14        version badness                                              5        0
  15        default values of variants not being used (non-roots)        0        0
  16        non-preferred compilers                                      0        0
  17        target mismatches                                            0        0
  18        non-preferred targets                                        0        0
  19        compiler mismatches (runtimes)                               0        0
  20        version badness (runtimes)                                   0        0
  21        non-preferred targets (runtimes)                             0        0
  22        edge wiring                                                  0        0

[+]  [email protected]=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

$ spack find zlib-ng
-- darwin-sonoma-m1 / [email protected] ------------------------
[email protected]  [email protected]=2.1.5
==> 2 installed packages

Re-use should be picking up the non-git ref install. According to how we have written satisfies for GitRefVersions and StandardVersions, and my memory, it should be impossible for a GitRefVersion to get picked. Or at least that was the goal. Will need to dig deeper into this before this can be merged.

lib/spack/spack/solver/asp.py

Co-authored-by: Greg Becker <[email protected]>

psakievich · 2024-04-26T12:39:18Z

I"m not so sure the issue with reuse I outlined is an issue. Basically, spack is picking the latest install that meets the spec requirements. If I do:

$ spack install zlib-ng@3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5
[+] /Users/psakiev/scratch/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gmake-4.4.1-yg5a2ohrgzyd532q2wnw5agfpzqgqfsb
[+] /Users/psakiev/scratch/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gnuconfig-2022-09-17-7gytrfuudfw2tpponhl5i4x4xtmbb6wc
==> Installing zlib-ng-3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5-q4dw5qjorcvw7bwp7svflr6fnmd6e2lg [3/3]
==> No binary for zlib-ng-3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5-q4dw5qjorcvw7bwp7svflr6fnmd6e2lg found: installing from source
==> No patches needed for zlib-ng
==> zlib-ng: Executing phase: 'autoreconf'
==> zlib-ng: Executing phase: 'configure'
==> zlib-ng: Executing phase: 'build'
==> zlib-ng: Executing phase: 'install'
==> zlib-ng: Successfully installed zlib-ng-3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5-q4dw5qjorcvw7bwp7svflr6fnmd6e2lg
  Stage: 10.90s.  Autoreconf: 0.38s.  Configure: 8.93s.  Build: 1.59s.  Install: 0.18s.  Post-install: 0.05s.  Total: 22.18s
[+] /Users/psakiev/scratch/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/zlib-ng-3f35bfccff2d1dacdfe9844712be1e042d028700_2.1.5-q4dw5qjorcvw7bwp7svflr6fnmd6e2lg
;As1082338:spack psakiev$ ng3f35bfccff2d1dacd@3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5

$ spack solve zlib-ng
==> Best of 5 considered solutions.
==> Optimization Criteria:
  Priority  Criterion                                            Installed  ToBuild
  1         number of packages to build (vs. reuse)                      -        0
  2         number of nodes from the same package                        -        0
  3         requirement weight                                           0        0
  4         deprecated versions used                                     0        0
  5         version weight                                               5        0
  6         number of non-default variants (roots)                       0        0
  7         preferred providers for roots                                0        0
  8         default values of variants not being used (roots)            0        0
  9         number of non-default variants (non-roots)                   0        0
  10        preferred providers (non-roots)                              0        0
  11        compiler mismatches that are not from CLI                    0        0
  12        compiler mismatches that are not from CLI                    0        0
  13        non-preferred OS's                                           0        0
  14        version badness                                              5        0
  15        default values of variants not being used (non-roots)        0        0
  16        non-preferred compilers                                      0        0
  17        target mismatches                                            0        0
  18        non-preferred targets                                        0        0
  19        compiler mismatches (runtimes)                               0        0
  20        version badness (runtimes)                                   0        0
  21        non-preferred targets (runtimes)                             0        0
  22        edge wiring                                                  0        0

[+]  zlib-ng@3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

It is picking the latest install, but to be fair to the concretizer, it is just the latest spec installed that meets the criteria I gave.

This one I think could be wrong, given a StandardVersion install already exists?

$ spack solve zlib-ng@2
==> Best of 4 considered solutions.
==> Optimization Criteria:
  Priority  Criterion                                            Installed  ToBuild
  1         number of packages to build (vs. reuse)                      -        0
  2         number of nodes from the same package                        -        0
  3         requirement weight                                           0        0
  4         deprecated versions used                                     0        0
  5         version weight                                               5        0
  6         number of non-default variants (roots)                       0        0
  7         preferred providers for roots                                0        0
  8         default values of variants not being used (roots)            0        0
  9         number of non-default variants (non-roots)                   0        0
  10        preferred providers (non-roots)                              0        0
  11        compiler mismatches that are not from CLI                    0        0
  12        compiler mismatches that are not from CLI                    0        0
  13        non-preferred OS's                                           0        0
  14        version badness                                              5        0
  15        default values of variants not being used (non-roots)        0        0
  16        non-preferred compilers                                      0        0
  17        target mismatches                                            0        0
  18        non-preferred targets                                        0        0
  19        compiler mismatches (runtimes)                               0        0
  20        version badness (runtimes)                                   0        0
  21        non-preferred targets (runtimes)                             0        0
  22        edge wiring                                                  0        0

[+]  zlib-ng@3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

This one is most certainly wrong since @2.1.5 is installed:

$ spack solve [email protected]
==> Best of 3 considered solutions.
==> Optimization Criteria:
  Priority  Criterion                                            Installed  ToBuild
  1         number of packages to build (vs. reuse)                      -        0
  2         number of nodes from the same package                        -        0
  3         requirement weight                                           0        0
  4         deprecated versions used                                     0        0
  5         version weight                                               5        0
  6         number of non-default variants (roots)                       0        0
  7         preferred providers for roots                                0        0
  8         default values of variants not being used (roots)            0        0
  9         number of non-default variants (non-roots)                   0        0
  10        preferred providers (non-roots)                              0        0
  11        compiler mismatches that are not from CLI                    0        0
  12        compiler mismatches that are not from CLI                    0        0
  13        non-preferred OS's                                           0        0
  14        version badness                                              5        0
  15        default values of variants not being used (non-roots)        0        0
  16        non-preferred compilers                                      0        0
  17        target mismatches                                            0        0
  18        non-preferred targets                                        0        0
  19        compiler mismatches (runtimes)                               0        0
  20        version badness (runtimes)                                   0        0
  21        non-preferred targets (runtimes)                             0        0
  22        edge wiring                                                  0        0

[+]  zlib-ng@3f35bfccff2d1dacdfe9844712be1e042d028700=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

Interested in thoughts? @tgamblin @becker33 @alalazo ?

What are the conditions for re-use we would want to impose on re-use for GitRefVersions currently? and for the scenario when every branch based version gets converted to a GitRefVersion during concretization?

psakievich · 2024-04-26T13:41:47Z

Still thinking about this, but don't have a chance to work on it again yet. My current thought is we need to add a line to the concretizer that does something like:

if prior_install.version is GitRefVersion && spec.version != prior_install.version:
   assign super heigh weight to prior_install

The issue is we can't just rely on satisfies b/c we need a GitRefVersion.satisifies(StandardVersion) to evaluate to true for the rest of the concretizer logic. Currently we have it so StandardVersion can not satisfy GitRefVersion as shown here but that is clearly not sufficient.

psakievich · 2024-04-26T15:18:20Z

Latest push fixes the issue above. Separate provenance for installs that are standard versions vs git versions allows the concretizer to prefer standard versions again. Now reuse won't consider git versions first unless they are the only thing installed, and this implicitly restores the requirement that GitVersions have to match exactly since only GItVersions should be considered for reuse when a GitVersion shows up in the DAG.

$ spack solve --show solutions [email protected]=2.1.4 \
> && spack solve --show solutions [email protected]=2.1 \
> && spack solve --show solutions [email protected]=2.1.5 \
> && spack solve --show solutions [email protected]=2.1.5

 -   [email protected]=2.1.4%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

 -   [email protected]=2.1%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

 -   [email protected]=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

[+]  [email protected]=2.1.5%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sonoma-m1
[+]      ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sonoma-m1
[+]      ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sonoma-m1

lib/spack/spack/solver/asp.py

psakievich · 2024-04-29T20:39:47Z

Both of my tests are not working as expected. From a debugger it looks like the installs aren't getting stored in the database so I can't test re-use that way.

psakievich · 2024-04-29T22:37:51Z

Needed an additional mock due to a missing dependency on gcc-runtime in all mock packages. I confirmed that the tests I added fail on develop in the expected manner, and now pass with this PR.

Questions for reviewers:
~~1) Should I swap the package being tested for something more standard? I need at least 1 variant, and git attributes for these tests~~
2) Should the mock on runtime requirements be extended to a more general mock?

jmcarcell · 2024-05-18T08:48:33Z

Interesting. If you run into that will you compare the DAG hashes and confirm they are different. There are many things that can cause that behavior. I would not expect this PR to, but it never hurts to check. Feel free to DM me on slack as well.

I found out that what was happening was that the cxxstd of xrootd was being either concretized to 11 or 14 (so I would install and then it would change the cxxstd needing a rebuild of all the dependents of xrootd and I remember repeating this process a few times), without changing anything else. Hardcoding the cxxstd of xrootd fixed that but I don't have any evidence that it was caused by this PR. After hardcoding cxxstd I haven't found any problems, and we have nightly builds with many packages using @hash=develop

lib/spack/spack/test/concretize.py

var/spack/repos/builtin.mock/packages/zlib-ng/package.py

lib/spack/spack/solver/asp.py

psakievich · 2024-05-29T18:06:55Z

@spackbot fix style

spackbot-app · 2024-05-29T18:06:58Z

Let me see if I can fix that for you!

spackbot-app · 2024-05-29T18:08:25Z

I was able to run spack style --fix for you!

spack style --fix

==> Running style checks on spack
  selected: isort, black, flake8, mypy
==> Modified files
  lib/spack/spack/solver/asp.py
  lib/spack/spack/test/concretize.py
  var/spack/repos/builtin.mock/packages/git-ref-package/package.py
==> Running isort checks
  isort checks were clean
==> Running black checks
reformatted var/spack/repos/builtin.mock/packages/git-ref-package/package.py
All done! ✨ 🍰 ✨
1 file reformatted, 2 files left unchanged.
  black checks were clean
==> Running flake8 checks
var/spack/repos/builtin.mock/packages/git-ref-package/package.py:6: [F401] 'spack.build_systems.autotools' imported but unused
var/spack/repos/builtin.mock/packages/git-ref-package/package.py:6: [F401] 'spack.build_systems.cmake' imported but unused
  flake8 found errors
==> Running mypy checks
lib/spack/spack/version/version_types.py:145: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:452: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:481: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
Found 3 errors in 1 file (checked 625 source files)
  mypy found errors

Keep in mind that I cannot fix your flake8 or mypy errors, so if you have any you'll need to fix them and update the pull request. If I was able to push to your branch, if you make further changes you will need to pull from your updated branch before pushing again.

I've updated the branch with style fixes.

psakievich · 2024-05-30T03:32:05Z

@spackbot fix style

spackbot-app · 2024-05-30T03:32:08Z

Let me see if I can fix that for you!

spackbot-app · 2024-05-30T03:33:36Z

I was able to run spack style --fix for you!

spack style --fix

==> Running style checks on spack
  selected: isort, black, flake8, mypy
==> Modified files
  lib/spack/spack/solver/asp.py
  lib/spack/spack/test/concretize.py
  var/spack/repos/builtin.mock/packages/git-ref-package/package.py
==> Running isort checks
  isort checks were clean
==> Running black checks
reformatted lib/spack/spack/test/concretize.py
reformatted lib/spack/spack/solver/asp.py
All done! ✨ 🍰 ✨
2 files reformatted, 1 file left unchanged.
  black checks were clean
==> Running flake8 checks
lib/spack/spack/test/concretize.py:2930: [E501] line too long (100 > 99 characters)
  flake8 found errors
==> Running mypy checks
lib/spack/spack/version/version_types.py:145: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:452: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
lib/spack/spack/version/version_types.py:481: error: Argument 2 to "StandardVersion" has incompatible type "*Tuple[Tuple[Any, ...], Tuple[Any, ...]]"; expected "Tuple[Tuple[Any, ...], Tuple[Any, ...]]"  [arg-type]
Found 3 errors in 1 file (checked 625 source files)
  mypy found errors

Keep in mind that I cannot fix your flake8 or mypy errors, so if you have any you'll need to fix them and update the pull request. If I was able to push to your branch, if you make further changes you will need to pull from your updated branch before pushing again.

I've updated the branch with style fixes.

lib/spack/spack/test/concretize.py

Co-authored-by: Greg Becker <[email protected]>

This reverts commit 17223fc.

@spackbot

* Preserve higher weight for CLI git ref versions Currently the concretizer fails if you reuse a git ref version that has already been installed but modify the spec at all. See spack#38484 for futher diagnosis The issue here is that since there is no established provenance for these versions the highest weight they are currently assigned is that of prior install. Re-use checks then fail because the weight of the version is identical to the solver. Ironically, these versions are given the highest weights possible when specified on the CLI for the first time. They should only appear in a DAG if they are an exact match or if the user specifies them at the CLI. Therefore it makes sense to preserve their higher ordering. Getting this right is critical to moving all branch based versions to a pinned git-ref in the future. * [@spackbot] updating style on behalf of psakievich * Update lib/spack/spack/solver/asp.py Co-authored-by: Greg Becker <[email protected]> * Add provenance specific to git ref installs * Sensitvity to name that I could not track down * Add regression test * Adjust test * Add prefer standard unit-test * Style * Add required mock * Format and mark * Make unit-test case reproduce CLI investigation * Remove unnecessary mock package * [@spackbot] updating style on behalf of psakievich * Use already developed fixture * Add zlib-ng to mocks again * Remove accidental adds * Remove maintainer * [@spackbot] updating style on behalf of psakievich * Rename test file * [@spackbot] updating style on behalf of psakievich * Remove unused imports * Update tests * [@spackbot] updating style on behalf of psakievich * Style * Update lib/spack/spack/test/concretize.py Co-authored-by: Greg Becker <[email protected]> * Update solver rule * Duplicate installed rules for installed_git_version * Revert "Duplicate installed rules for installed_git_version" This reverts commit 17223fc. --------- Co-authored-by: psakievich <[email protected]> Co-authored-by: Greg Becker <[email protected]>

@spackbot

* Preserve higher weight for CLI git ref versions Currently the concretizer fails if you reuse a git ref version that has already been installed but modify the spec at all. See spack#38484 for futher diagnosis The issue here is that since there is no established provenance for these versions the highest weight they are currently assigned is that of prior install. Re-use checks then fail because the weight of the version is identical to the solver. Ironically, these versions are given the highest weights possible when specified on the CLI for the first time. They should only appear in a DAG if they are an exact match or if the user specifies them at the CLI. Therefore it makes sense to preserve their higher ordering. Getting this right is critical to moving all branch based versions to a pinned git-ref in the future. * [@spackbot] updating style on behalf of psakievich * Update lib/spack/spack/solver/asp.py Co-authored-by: Greg Becker <[email protected]> * Add provenance specific to git ref installs * Sensitvity to name that I could not track down * Add regression test * Adjust test * Add prefer standard unit-test * Style * Add required mock * Format and mark * Make unit-test case reproduce CLI investigation * Remove unnecessary mock package * [@spackbot] updating style on behalf of psakievich * Use already developed fixture * Add zlib-ng to mocks again * Remove accidental adds * Remove maintainer * [@spackbot] updating style on behalf of psakievich * Rename test file * [@spackbot] updating style on behalf of psakievich * Remove unused imports * Update tests * [@spackbot] updating style on behalf of psakievich * Style * Update lib/spack/spack/test/concretize.py Co-authored-by: Greg Becker <[email protected]> * Update solver rule * Duplicate installed rules for installed_git_version * Revert "Duplicate installed rules for installed_git_version" This reverts commit 17223fc. --------- Co-authored-by: psakievich <[email protected]> Co-authored-by: Greg Becker <[email protected]>

@spackbot

* Preserve higher weight for CLI git ref versions Currently the concretizer fails if you reuse a git ref version that has already been installed but modify the spec at all. See spack#38484 for futher diagnosis The issue here is that since there is no established provenance for these versions the highest weight they are currently assigned is that of prior install. Re-use checks then fail because the weight of the version is identical to the solver. Ironically, these versions are given the highest weights possible when specified on the CLI for the first time. They should only appear in a DAG if they are an exact match or if the user specifies them at the CLI. Therefore it makes sense to preserve their higher ordering. Getting this right is critical to moving all branch based versions to a pinned git-ref in the future. * [@spackbot] updating style on behalf of psakievich * Update lib/spack/spack/solver/asp.py Co-authored-by: Greg Becker <[email protected]> * Add provenance specific to git ref installs * Sensitvity to name that I could not track down * Add regression test * Adjust test * Add prefer standard unit-test * Style * Add required mock * Format and mark * Make unit-test case reproduce CLI investigation * Remove unnecessary mock package * [@spackbot] updating style on behalf of psakievich * Use already developed fixture * Add zlib-ng to mocks again * Remove accidental adds * Remove maintainer * [@spackbot] updating style on behalf of psakievich * Rename test file * [@spackbot] updating style on behalf of psakievich * Remove unused imports * Update tests * [@spackbot] updating style on behalf of psakievich * Style * Update lib/spack/spack/test/concretize.py Co-authored-by: Greg Becker <[email protected]> * Update solver rule * Duplicate installed rules for installed_git_version * Revert "Duplicate installed rules for installed_git_version" This reverts commit 17223fc. --------- Co-authored-by: psakievich <[email protected]> Co-authored-by: Greg Becker <[email protected]>

spackbot-app bot added the core PR affects Spack core functionality label Apr 26, 2024

[@spackbot] updating style on behalf of psakievich

17761f3

becker33 reviewed Apr 26, 2024

View reviewed changes

lib/spack/spack/solver/asp.py Outdated Show resolved Hide resolved

Update lib/spack/spack/solver/asp.py

9cd7fd1

Co-authored-by: Greg Becker <[email protected]>

Add provenance specific to git ref installs

c8ab35e

Sensitvity to name that I could not track down

317ecd8

psakievich commented Apr 26, 2024

View reviewed changes

lib/spack/spack/solver/asp.py Show resolved Hide resolved

psakievich requested a review from becker33 April 26, 2024 19:13

Add regression test

93ff027

tgamblin self-requested a review April 29, 2024 17:49

tgamblin self-assigned this Apr 29, 2024

tgamblin added this to the v0.22.0 milestone Apr 29, 2024

psakievich added 2 commits April 29, 2024 13:44

Adjust test

669ca81

Add prefer standard unit-test

9ef7a3c

spackbot-app bot added new-variant tests General test capability(ies) labels Apr 29, 2024

Style

691e323

Add required mock

abd383d

psakievich marked this pull request as ready for review April 29, 2024 22:38

psakievich mentioned this pull request Apr 29, 2024

Internal error when installing multiple variants of one package with @git.branch=version syntax #38484

Closed

3 tasks

psakievich mentioned this pull request May 22, 2024

Pin git sha to git ref based versions #44319

Closed

4 tasks

becker33 requested changes May 28, 2024

View reviewed changes

lib/spack/spack/test/concretize.py Outdated Show resolved Hide resolved

lib/spack/spack/test/concretize.py Show resolved Hide resolved

var/spack/repos/builtin.mock/packages/zlib-ng/package.py Outdated Show resolved Hide resolved

lib/spack/spack/solver/asp.py Outdated Show resolved Hide resolved

Rename test file

b04e794

[@spackbot] updating style on behalf of psakievich

2117c1c

psakievich added 2 commits May 29, 2024 12:19

Remove unused imports

ca5b085

Update tests

36fb235

[@spackbot] updating style on behalf of psakievich

08495e0

Style

aa25fb9

becker33 requested changes May 31, 2024

View reviewed changes

lib/spack/spack/test/concretize.py Outdated Show resolved Hide resolved

psakievich and others added 4 commits June 7, 2024 08:54

Update lib/spack/spack/test/concretize.py

08b8c9e

Co-authored-by: Greg Becker <[email protected]>

Update solver rule

fa159b6

Duplicate installed rules for installed_git_version

17223fc

Merge branch 'develop' into psakiev/bug-gitref-reuse

a321285

psakievich requested a review from becker33 June 11, 2024 14:37

Revert "Duplicate installed rules for installed_git_version"

6110985

This reverts commit 17223fc.

becker33 approved these changes Jun 11, 2024

View reviewed changes

psakievich merged commit 337bf3b into spack:develop Jun 11, 2024

psakievich mentioned this pull request Jun 14, 2024

spack fails to concretize if there are built packages when using develop packages #44160

Closed

3 tasks

greenc-FNAL mentioned this pull request Jul 30, 2024

Update from upstream 2024-07-22 and re-apply scopes FNALssi/spack#408

Merged

cameronrutherford mentioned this pull request Sep 3, 2024

Use git@version syntax for spack pipelines and buildcache pnnl/ExaGO#157

Closed

Conversation

psakievich commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TLDR:

Original Post

Uh oh!

psakievich commented Apr 26, 2024

Uh oh!

spackbot-app bot commented Apr 26, 2024

Uh oh!

spackbot-app bot commented Apr 26, 2024

Uh oh!

psakievich commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

psakievich commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

psakievich commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

psakievich commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

psakievich commented Apr 29, 2024

Uh oh!

psakievich commented Apr 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmcarcell commented May 18, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

psakievich commented May 29, 2024

Uh oh!

spackbot-app bot commented May 29, 2024

Uh oh!

spackbot-app bot commented May 29, 2024

Uh oh!

psakievich commented May 30, 2024

Uh oh!

spackbot-app bot commented May 30, 2024

Uh oh!

spackbot-app bot commented May 30, 2024

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

psakievich commented Apr 26, 2024 •

edited

Loading

psakievich commented Apr 26, 2024 •

edited

Loading

psakievich commented Apr 26, 2024 •

edited

Loading

psakievich commented Apr 26, 2024 •

edited

Loading

psakievich commented Apr 26, 2024 •

edited

Loading

psakievich commented Apr 29, 2024 •

edited

Loading