fix style

thank you @tldahlgren

.codecov.yml

@@ -5,7 +5,7 @@ coverage:
   status:
     project:
       default:
-        threshold: 2.0%
+        threshold: 0.2%
 
 ignore:
   - lib/spack/spack/test/.*

.devcontainer/postCreateCommand.sh

@@ -1,20 +0,0 @@
-#!/bin/bash
-
-# Load spack environment at terminal startup
-cat <<EOF >> /root/.bashrc
-. /workspaces/spack/share/spack/setup-env.sh
-EOF
-
-# Load spack environment in this script
-. /workspaces/spack/share/spack/setup-env.sh
-
-# Ensure generic targets for maximum matching with buildcaches
-spack config --scope site add "packages:all:require:[target=x86_64_v3]"
-spack config --scope site add "concretizer:targets:granularity:generic"
-
-# Find compiler and install gcc-runtime
-spack compiler find --scope site
-
-# Setup buildcaches
-spack mirror add --scope site develop https://binaries.spack.io/develop
-spack buildcache keys --install --trust

.devcontainer/ubuntu20.04/devcontainer.json

@@ -1,5 +0,0 @@
-{
-  "name": "Ubuntu 20.04",
-  "image": "ghcr.io/spack/ubuntu20.04-runner-amd64-gcc-11.4:2023.08.01",
-  "postCreateCommand": "./.devcontainer/postCreateCommand.sh"
-}

.devcontainer/ubuntu22.04/devcontainer.json

@@ -1,5 +0,0 @@
-{
-  "name": "Ubuntu 22.04",
-  "image": "ghcr.io/spack/ubuntu-22.04:v2024-05-07",
-  "postCreateCommand": "./.devcontainer/postCreateCommand.sh"
-}

.github/dependabot.yml

@@ -5,10 +5,13 @@ updates:
     directory: "/"
     schedule:
       interval: "daily"
-  # Requirements to run style checks and build documentation
+  # Requirements to build documentation
   - package-ecosystem: "pip"
-    directories:
-     - "/.github/workflows/requirements/style/*"
-     - "/lib/spack/docs"
+    directory: "/lib/spack/docs"
+    schedule:
+      interval: "daily"
+  # Requirements to run style checks
+  - package-ecosystem: "pip"
+    directory: "/.github/workflows/style"
     schedule:
       interval: "daily"

.github/pull_request_template.md

@@ -1,6 +0,0 @@
-<!--  
-Remember that `spackbot` can help with your PR in multiple ways:
-- `@spackbot help` shows all the commands that are currently available
-- `@spackbot fix style` tries to push a commit to fix style issues in this PR
-- `@spackbot re-run pipeline` runs the pipelines again, if you have write access to the repository 
--->

.github/workflows/audit.yaml

@@ -17,58 +17,33 @@ concurrency:
 jobs:
   # Run audits on all the packages in the built-in repository
   package-audits:
-    runs-on: ${{ matrix.system.os }}
+    runs-on: ${{ matrix.operating_system }}
     strategy:
       matrix:
-        system:
-        - { os: windows-latest, shell: 'powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}' }
-        - { os: ubuntu-latest, shell: bash }
-        - { os: macos-latest, shell: bash }
-    defaults:
-      run:
-        shell: ${{ matrix.system.shell }}
+        operating_system: ["ubuntu-latest", "macos-latest"]
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
       with:
         python-version: ${{inputs.python_version}}
     - name: Install Python packages
       run: |
         pip install --upgrade pip setuptools pytest coverage[toml]
-    - name: Setup for Windows run
-      if: runner.os == 'Windows'
-      run: |
-        python -m pip install --upgrade pywin32
     - name: Package audits (with coverage)
-      env:
-          COVERAGE_FILE: coverage/.coverage-audits-${{ matrix.system.os }}
-      if: ${{ inputs.with_coverage == 'true' && runner.os != 'Windows' }}
+      if: ${{ inputs.with_coverage == 'true' }}
       run: |
           . share/spack/setup-env.sh
           coverage run $(which spack) audit packages
-          coverage run $(which spack) audit configs
-          coverage run $(which spack) -d audit externals
+          coverage run $(which spack) audit externals        
           coverage combine
+          coverage xml
     - name: Package audits (without coverage)
-      if: ${{ inputs.with_coverage == 'false' && runner.os != 'Windows' }}
+      if: ${{ inputs.with_coverage == 'false' }}
       run: |
           . share/spack/setup-env.sh
-          spack -d audit packages
-          spack -d audit configs
-          spack -d audit externals
-    - name: Package audits (without coverage)
-      if: ${{ runner.os == 'Windows' }}
-      run: |
-          . share/spack/setup-env.sh
-          spack -d audit packages
-          ./share/spack/qa/validate_last_exit.ps1
-          spack -d audit configs
-          ./share/spack/qa/validate_last_exit.ps1
-          spack -d audit externals
-          ./share/spack/qa/validate_last_exit.ps1
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
-      if: ${{ inputs.with_coverage == 'true' && runner.os != 'Windows' }}
+          $(which spack) audit packages
+          $(which spack) audit externals
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d # @v2.1.0
+      if: ${{ inputs.with_coverage == 'true' }}
       with:
-        name: coverage-audits-${{ matrix.system.os }}
-        path: coverage
-        include-hidden-files: true
+        flags: unittests,audits

.github/workflows/bootstrap-test.sh

@@ -1,8 +1,7 @@
 #!/bin/bash
-set -e
+set -ex
 source share/spack/setup-env.sh
-$PYTHON bin/spack bootstrap disable github-actions-v0.5
 $PYTHON bin/spack bootstrap disable spack-install
-$PYTHON bin/spack $SPACK_FLAGS solve zlib
+$PYTHON bin/spack -d solve zlib
 tree $BOOTSTRAP/store
 exit 0

.github/workflows/bootstrap.yml

@@ -13,22 +13,118 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-  distros-clingo-sources:
+  fedora-clingo-sources:
     runs-on: ubuntu-latest
-    container: ${{ matrix.image }}
-    strategy:
-      matrix:
-        image: ["fedora:latest", "opensuse/leap:latest"]
+    container: "fedora:latest"
     steps:
-      - name: Setup Fedora
-        if: ${{ matrix.image == 'fedora:latest' }}
+      - name: Install dependencies
         run: |
           dnf install -y \
-              bzip2 curl file gcc-c++ gcc gcc-gfortran git gzip \
+              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
               make patch unzip which xz python3 python3-devel tree \
               cmake bison bison-devel libstdc++-static
-      - name: Setup OpenSUSE
-        if: ${{ matrix.image == 'opensuse/leap:latest' }}
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+        with:
+          fetch-depth: 0
+      - name: Setup non-root user
+        run: |
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          useradd spack-test && mkdir -p ~spack-test
+          chown -R spack-test . ~spack-test
+      - name: Setup repo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap clingo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.4
+          spack external find cmake bison
+          spack -d solve zlib
+          tree ~/.spack/bootstrap/store/
+
+  ubuntu-clingo-sources:
+    runs-on: ubuntu-latest
+    container: "ubuntu:latest"
+    steps:
+      - name: Install dependencies
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update -y && apt-get upgrade -y
+          apt-get install -y \
+              bzip2 curl file g++ gcc gfortran git gnupg2 gzip \
+              make patch unzip xz-utils python3 python3-dev tree \
+              cmake bison
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+        with:
+          fetch-depth: 0
+      - name: Setup non-root user
+        run: |
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          useradd spack-test && mkdir -p ~spack-test
+          chown -R spack-test . ~spack-test
+      - name: Setup repo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap clingo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.4
+          spack external find cmake bison
+          spack -d solve zlib
+          tree ~/.spack/bootstrap/store/
+
+  ubuntu-clingo-binaries-and-patchelf:
+    runs-on: ubuntu-latest
+    container: "ubuntu:latest"
+    steps:
+      - name: Install dependencies
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update -y && apt-get upgrade -y
+          apt-get install -y \
+              bzip2 curl file g++ gcc gfortran git gnupg2 gzip \
+              make patch unzip xz-utils python3 python3-dev tree
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+        with:
+          fetch-depth: 0
+      - name: Setup non-root user
+        run: |
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          useradd spack-test && mkdir -p ~spack-test
+          chown -R spack-test . ~spack-test
+      - name: Setup repo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap clingo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack -d solve zlib
+          tree ~/.spack/bootstrap/store/
+
+  opensuse-clingo-sources:
+    runs-on: ubuntu-latest
+    container: "opensuse/leap:latest"
+    steps:
+      - name: Install dependencies
         run: |
           # Harden CI by applying the workaround described here: https://www.suse.com/support/kb/doc/?id=000019505
           zypper update -y || zypper update -y
@@ -37,117 +133,101 @@ jobs:
               make patch unzip which xz python3 python3-devel tree \
               cmake bison
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
         with:
           fetch-depth: 0
+      - name: Setup repo
+        run: |
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          git --version
+          . .github/workflows/setup_git.sh
       - name: Bootstrap clingo
         run: |
           source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.6
           spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.4
           spack external find cmake bison
           spack -d solve zlib
           tree ~/.spack/bootstrap/store/
 
-  clingo-sources:
-    runs-on: ${{ matrix.runner }}
-    strategy:
-      matrix:
-        runner: ['macos-13', 'macos-14', "ubuntu-latest"]
+  macos-clingo-sources:
+    runs-on: macos-latest
     steps:
-      - name: Setup macOS
-        if: ${{ matrix.runner != 'ubuntu-latest' }}
+      - name: Install dependencies
         run: |
-          brew install cmake bison tree
+          brew install cmake bison@2.7 tree
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+      - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
         with:
           python-version: "3.12"
       - name: Bootstrap clingo
         run: |
           source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.6
+          export PATH=/usr/local/opt/bison@2.7/bin:$PATH
           spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.4
           spack external find --not-buildable cmake bison
           spack -d solve zlib
-          tree $HOME/.spack/bootstrap/store/
-
-  gnupg-sources:
-    runs-on: ${{ matrix.runner }}
-    strategy:
-      matrix:
-        runner: [ 'macos-13', 'macos-14', "ubuntu-latest" ]
-    steps:
-      - name: Setup macOS
-        if: ${{ matrix.runner != 'ubuntu-latest' }}
-        run: brew install tree gawk
-      - name: Remove system executables
-        run: |
-          while [ -n "$(command -v gpg gpg2 patchelf)" ]; do
-            sudo rm $(command -v gpg gpg2 patchelf)
-          done
-      - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-        with:
-          fetch-depth: 0
-      - name: Bootstrap GnuPG
-        run: |
-          source share/spack/setup-env.sh
-          spack solve zlib
-          spack bootstrap disable github-actions-v0.6
-          spack bootstrap disable github-actions-v0.5
-          spack -d gpg list
           tree ~/.spack/bootstrap/store/
 
-  from-binaries:
-    runs-on: ${{ matrix.runner }}
+  macos-clingo-binaries:
+    runs-on: ${{ matrix.macos-version }}
     strategy:
       matrix:
-        runner: ['macos-13', 'macos-14', "ubuntu-latest"]
+        macos-version: ['macos-11', 'macos-12']
     steps:
-      - name: Setup macOS
-        if: ${{ matrix.runner != 'ubuntu-latest' }}
-        run: brew install tree
-      - name: Remove system executables
+      - name: Install dependencies
         run: |
-          while [ -n "$(command -v gpg gpg2 patchelf)" ]; do
-            sudo rm $(command -v gpg gpg2 patchelf)
-          done
+          brew install tree
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-        with:
-          python-version: |
-            3.8
-            3.9
-            3.10
-            3.11
-            3.12
-            3.13
-      - name: Set bootstrap sources
-        run: |
-          source share/spack/setup-env.sh
-          spack bootstrap disable github-actions-v0.5
-          spack bootstrap disable spack-install
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
       - name: Bootstrap clingo
         run: |
-          set -e
-          for ver in '3.8' '3.9' '3.10' '3.11' '3.12' '3.13'; do
+          set -ex
+          for ver in '3.7' '3.8' '3.9' '3.10' '3.11' ; do
             not_found=1
             ver_dir="$(find $RUNNER_TOOL_CACHE/Python -wholename "*/${ver}.*/*/bin" | grep . || true)"
+            echo "Testing $ver_dir"
             if [[ -d "$ver_dir" ]] ; then
-              echo "Testing $ver_dir"
               if $ver_dir/python --version ; then
                 export PYTHON="$ver_dir/python"
                 not_found=0
                 old_path="$PATH"
                 export PATH="$ver_dir:$PATH"
-                ./bin/spack-tmpconfig -b ./.github/workflows/bin/bootstrap-test.sh
+                ./bin/spack-tmpconfig -b ./.github/workflows/bootstrap-test.sh
+                export PATH="$old_path"
+              fi
+            fi
+            # NOTE: test all pythons that exist, not all do on 12
+          done
+
+  ubuntu-clingo-binaries:
+    runs-on: ubuntu-20.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+        with:
+          fetch-depth: 0
+      - name: Setup repo
+        run: |
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap clingo
+        run: |
+          set -ex
+          for ver in '3.7' '3.8' '3.9' '3.10' '3.11' ; do
+            not_found=1
+            ver_dir="$(find $RUNNER_TOOL_CACHE/Python -wholename "*/${ver}.*/*/bin" | grep . || true)"
+            echo "Testing $ver_dir"
+            if [[ -d "$ver_dir" ]] ; then
+              if $ver_dir/python --version ; then
+                export PYTHON="$ver_dir/python"
+                not_found=0
+                old_path="$PATH"
+                export PATH="$ver_dir:$PATH"
+                ./bin/spack-tmpconfig -b ./.github/workflows/bootstrap-test.sh
                 export PATH="$old_path"
               fi
             fi
@@ -156,49 +236,122 @@ jobs:
               exit 1
             fi
           done
-      - name: Bootstrap GnuPG
-        run: |
-          source share/spack/setup-env.sh
-          spack -d gpg list
-          tree $HOME/.spack/bootstrap/store/
-      - name: Bootstrap File
-        run: |
-          source share/spack/setup-env.sh
-          spack -d python share/spack/qa/bootstrap-file.py
-          tree $HOME/.spack/bootstrap/store/
 
-  windows:
-    runs-on: "windows-latest"
+  ubuntu-gnupg-binaries:
+    runs-on: ubuntu-latest
+    container: "ubuntu:latest"
     steps:
+      - name: Install dependencies
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update -y && apt-get upgrade -y
+          apt-get install -y \
+              bzip2 curl file g++ gcc patchelf gfortran git gzip \
+              make patch unzip xz-utils python3 python3-dev tree
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
         with:
           fetch-depth: 0
-      - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+      - name: Setup non-root user
+        run: |
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          useradd spack-test && mkdir -p ~spack-test
+          chown -R spack-test . ~spack-test
+      - name: Setup repo
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap GnuPG
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack bootstrap disable github-actions-v0.4
+          spack bootstrap disable spack-install
+          spack -d gpg list
+          tree ~/.spack/bootstrap/store/
+
+  ubuntu-gnupg-sources:
+    runs-on: ubuntu-latest
+    container: "ubuntu:latest"
+    steps:
+      - name: Install dependencies
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update -y && apt-get upgrade -y
+          apt-get install -y \
+              bzip2 curl file g++ gcc patchelf gfortran git gzip \
+              make patch unzip xz-utils python3 python3-dev tree \
+              gawk
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
         with:
-          python-version: "3.12"
-      - name: Setup Windows
+          fetch-depth: 0
+      - name: Setup non-root user
         run: |
-          Remove-Item -Path (Get-Command gpg).Path
-          Remove-Item -Path (Get-Command file).Path
-      - name: Bootstrap clingo
+          # See [1] below
+          git config --global --add safe.directory /__w/spack/spack
+          useradd spack-test && mkdir -p ~spack-test
+          chown -R spack-test . ~spack-test
+      - name: Setup repo
+        shell: runuser -u spack-test -- bash {0}
         run: |
-          ./share/spack/setup-env.ps1
-          spack bootstrap disable github-actions-v0.6
+          git --version
+          . .github/workflows/setup_git.sh
+      - name: Bootstrap GnuPG
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack solve zlib
           spack bootstrap disable github-actions-v0.5
-          spack external find --not-buildable cmake bison
-          spack -d solve zlib
-          ./share/spack/qa/validate_last_exit.ps1
-          tree $env:userprofile/.spack/bootstrap/store/
+          spack bootstrap disable github-actions-v0.4
+          spack -d gpg list
+          tree ~/.spack/bootstrap/store/
+
+  macos-gnupg-binaries:
+    runs-on: macos-latest
+    steps:
+      - name: Install dependencies
+        run: |
+          brew install tree
+          # Remove GnuPG since we want to bootstrap it
+          sudo rm -rf /usr/local/bin/gpg
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
       - name: Bootstrap GnuPG
         run: |
-          ./share/spack/setup-env.ps1
+          source share/spack/setup-env.sh
+          spack bootstrap disable github-actions-v0.4
+          spack bootstrap disable spack-install
           spack -d gpg list
-          ./share/spack/qa/validate_last_exit.ps1
-          tree $env:userprofile/.spack/bootstrap/store/
-      - name: Bootstrap File
+          tree ~/.spack/bootstrap/store/
+
+  macos-gnupg-sources:
+    runs-on: macos-latest
+    steps:
+      - name: Install dependencies
         run: |
-          ./share/spack/setup-env.ps1
-          spack -d python share/spack/qa/bootstrap-file.py
-          ./share/spack/qa/validate_last_exit.ps1
-          tree $env:userprofile/.spack/bootstrap/store/
+          brew install gawk tree
+          # Remove GnuPG since we want to bootstrap it
+          sudo rm -rf /usr/local/bin/gpg
+      - name: Checkout
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+      - name: Bootstrap GnuPG
+        run: |
+          source share/spack/setup-env.sh
+          spack solve zlib
+          spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.4
+          spack -d gpg list
+          tree ~/.spack/bootstrap/store/
+
+
+# [1] Distros that have patched git to resolve CVE-2022-24765 (e.g. Ubuntu patching v2.25.1)
+#     introduce breaking behaviorso we have to set `safe.directory` in gitconfig ourselves.
+#     See:
+#     - https://github.blog/2022-04-12-git-security-vulnerability-announced/
+#     - https://github.com/actions/checkout/issues/760
+#     - http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.25.1-1ubuntu3.3/changelog

.github/workflows/build-containers.yml

@@ -40,30 +40,24 @@ jobs:
         # 1: Platforms to build for
         # 2: Base image (e.g. ubuntu:22.04)
         dockerfile: [[amazon-linux, 'linux/amd64,linux/arm64', 'amazonlinux:2'],
-                     [centos-stream9, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:stream9'],
+                     [centos7, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:7'],
+                     [centos-stream, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:stream'],
                      [leap15, 'linux/amd64,linux/arm64,linux/ppc64le', 'opensuse/leap:15'],
                      [ubuntu-focal, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:20.04'],
                      [ubuntu-jammy, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:22.04'],
-                     [ubuntu-noble, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:24.04'],
                      [almalinux8, 'linux/amd64,linux/arm64,linux/ppc64le', 'almalinux:8'],
                      [almalinux9, 'linux/amd64,linux/arm64,linux/ppc64le', 'almalinux:9'],
                      [rockylinux8, 'linux/amd64,linux/arm64', 'rockylinux:8'],
                      [rockylinux9, 'linux/amd64,linux/arm64', 'rockylinux:9'],
-                     [fedora39, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:39'],
-                     [fedora40, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:40']]
+                     [fedora37, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:37'],
+                     [fedora38, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:38']]
     name: Build ${{ matrix.dockerfile[0] }}
     if: github.repository == 'spack/spack'
     steps:
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
 
-      - name: Determine latest release tag
-        id: latest
-        run: |
-          git fetch --quiet --tags
-          echo "tag=$(git tag --list --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1)" | tee -a $GITHUB_OUTPUT
-
-      - uses: docker/metadata-action@369eb591f429131d6889c46b94e711f089e6ca96
+      - uses: docker/metadata-action@dbef88086f6cef02e264edb7dbf63250c17cef6c
         id: docker_meta
         with:
           images: |
@@ -77,13 +71,12 @@ jobs:
               type=semver,pattern={{major}}
               type=ref,event=branch
               type=ref,event=pr
-              type=raw,value=latest,enable=${{ github.ref == format('refs/tags/{0}', steps.latest.outputs.tag) }}
 
       - name: Generate the Dockerfile
         env:
           SPACK_YAML_OS: "${{ matrix.dockerfile[2] }}"
         run: |
-          .github/workflows/bin/generate_spack_yaml_containerize.sh
+          .github/workflows/generate_spack_yaml_containerize.sh
           . share/spack/setup-env.sh
           mkdir -p dockerfiles/${{ matrix.dockerfile[0] }}
           spack containerize --last-stage=bootstrap | tee dockerfiles/${{ matrix.dockerfile[0] }}/Dockerfile
@@ -94,19 +87,19 @@ jobs:
           fi
 
       - name: Upload Dockerfile
-        uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
+        uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32
         with:
-          name: dockerfiles_${{ matrix.dockerfile[0] }}
+          name: dockerfiles
           path: dockerfiles
 
       - name: Set up QEMU
-        uses: docker/setup-qemu-action@49b3bc8e6bdd4a60e6116a5414239cba5943d3cf
+        uses: docker/setup-qemu-action@68827325e0b33c7199eb31dd4e31fbe9023e06e3
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@c47758b77c9736f4b2ef4073d4d51994fabfe349
+        uses: docker/setup-buildx-action@f95db51fddba0c2d1ec667646a06c2ce06100226
 
       - name: Log in to GitHub Container Registry
-        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567
+        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
         with:
           registry: ghcr.io
           username: ${{ github.actor }}
@@ -114,27 +107,18 @@ jobs:
 
       - name: Log in to DockerHub
         if: github.event_name != 'pull_request'
-        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567
+        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
         with:
           username: ${{ secrets.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Build & Deploy ${{ matrix.dockerfile[0] }}
-        uses: docker/build-push-action@48aba3b46d1b1fec4febb7c5d0c644b249a11355
+        uses: docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f42f56
         with:
           context: dockerfiles/${{ matrix.dockerfile[0] }}
           platforms: ${{ matrix.dockerfile[1] }}
           push: ${{ github.event_name != 'pull_request' }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
           tags: ${{ steps.docker_meta.outputs.tags }}
           labels: ${{ steps.docker_meta.outputs.labels }}
-
-  merge-dockerfiles:
-    runs-on: ubuntu-latest
-    needs: deploy-images
-    steps:
-      - name: Merge Artifacts
-        uses: actions/upload-artifact/merge@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
-        with:
-          name: dockerfiles
-          pattern: dockerfiles_*
-          delete-merged: true

.github/workflows/ci.yaml

@@ -15,6 +15,17 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
+  prechecks:
+    needs: [ changes ]
+    uses: ./.github/workflows/valid-style.yml
+    with:
+      with_coverage: ${{ needs.changes.outputs.core }}
+  all-prechecks:
+    needs: [ prechecks ]
+    runs-on: ubuntu-latest
+    steps:
+    - name: Success
+      run: "true"
   # Check which files have been updated by the PR
   changes:
     runs-on: ubuntu-latest
@@ -24,12 +35,12 @@ jobs:
       core: ${{ steps.filter.outputs.core }}
       packages: ${{ steps.filter.outputs.packages }}
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
         if: ${{ github.event_name == 'push' }}
         with:
           fetch-depth: 0
             # For pull requests it's not necessary to checkout the code
-      - uses: dorny/paths-filter@de90cc6fb38fc0963ad72b210f1f284cd68cea36
+      - uses: dorny/paths-filter@4512585405083f25c027a35db413c2b3b9006d50
         id: filter
         with:
           # See https://github.com/dorny/paths-filter/issues/56 for the syntax used below
@@ -41,13 +52,6 @@ jobs:
             - 'var/spack/repos/builtin/packages/clingo/**'
             - 'var/spack/repos/builtin/packages/python/**'
             - 'var/spack/repos/builtin/packages/re2c/**'
-            - 'var/spack/repos/builtin/packages/gnupg/**'
-            - 'var/spack/repos/builtin/packages/libassuan/**'
-            - 'var/spack/repos/builtin/packages/libgcrypt/**'
-            - 'var/spack/repos/builtin/packages/libgpg-error/**'
-            - 'var/spack/repos/builtin/packages/libksba/**'
-            - 'var/spack/repos/builtin/packages/npth/**'
-            - 'var/spack/repos/builtin/packages/pinentry/**'
             - 'lib/spack/**'
             - 'share/spack/**'
             - '.github/workflows/bootstrap.yml'
@@ -66,54 +70,17 @@ jobs:
     if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.bootstrap == 'true' }}
     needs: [ prechecks, changes ]
     uses: ./.github/workflows/bootstrap.yml
-    secrets: inherit
-
   unit-tests:
     if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.core == 'true' }}
     needs: [ prechecks, changes ]
     uses: ./.github/workflows/unit_tests.yaml
-    secrets: inherit
-
-  prechecks:
-    needs: [ changes ]
-    uses: ./.github/workflows/valid-style.yml
-    secrets: inherit
-    with:
-      with_coverage: ${{ needs.changes.outputs.core }}
-
-  all-prechecks:
+  windows:
+    if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.core == 'true' }}
     needs: [ prechecks ]
-    if: ${{ always() }}
+    uses: ./.github/workflows/windows_python.yml
+  all:
+    needs: [ windows, unit-tests, bootstrap ]
     runs-on: ubuntu-latest
     steps:
     - name: Success
-      run: |
-        if [ "${{ needs.prechecks.result }}" == "failure" ] || [ "${{ needs.prechecks.result }}" == "canceled" ]; then
-          echo "Unit tests failed." 
-          exit 1
-        else
-          exit 0
-        fi
-
-  coverage:
-    needs: [ unit-tests, prechecks ]
-    uses: ./.github/workflows/coverage.yml
-    secrets: inherit
-
-  all:
-    needs: [ unit-tests, coverage, bootstrap ]
-    if: ${{ always() }}
-    runs-on: ubuntu-latest
-    # See https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#needs-context
-    steps:
-    - name: Status summary
-      run: |
-        if [ "${{ needs.unit-tests.result }}" == "failure" ] || [ "${{ needs.unit-tests.result }}" == "canceled" ]; then
-          echo "Unit tests failed." 
-          exit 1
-        elif [ "${{ needs.bootstrap.result }}" == "failure" ] || [ "${{ needs.bootstrap.result }}" == "canceled" ]; then
-          echo "Bootstrap tests failed." 
-          exit 1
-        else
-          exit 0
-        fi
+      run: "true"

.github/workflows/coverage.yml

@@ -1,35 +0,0 @@
-name: coverage
-
-on:
-  workflow_call:
-
-jobs:
-  # Upload coverage reports to codecov once as a single bundle
-  upload:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-      with:
-        python-version: '3.11'
-        cache: 'pip'
-
-    - name: Install python dependencies
-      run: pip install -r .github/workflows/requirements/coverage/requirements.txt
-
-    - name: Download coverage artifact files
-      uses: actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16
-      with:
-        pattern: coverage-*
-        path: coverage
-        merge-multiple: true
-
-    - run: ls -la coverage
-    - run: coverage combine -a coverage/.coverage*
-    - run: coverage xml
-
-    - name: "Upload coverage report to CodeCov"
-      uses: codecov/codecov-action@05f5a9cfad807516dbbef9929c4a42df3eb78766
-      with:
-        verbose: true
-        fail_ci_if_error: true

.github/workflows/install_spack.sh

@@ -0,0 +1,8 @@
+#!/usr/bin/env sh
+. share/spack/setup-env.sh
+echo -e "config:\n  build_jobs: 2" > etc/spack/config.yaml
+spack config add "packages:all:target:[x86_64]"
+spack compiler find
+spack compiler info apple-clang
+spack debug report
+spack solve zlib

.github/workflows/nightly-win-builds.yml

@@ -14,10 +14,10 @@ jobs:
   build-paraview-deps:
     runs-on: windows-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
       with:
         python-version: 3.9
     - name: Install Python packages

.github/workflows/requirements/coverage/requirements.txt

@@ -1 +0,0 @@
-coverage==7.6.1

.github/workflows/requirements/style/requirements.txt

@@ -1,7 +0,0 @@
-black==24.10.0
-clingo==5.7.1
-flake8==7.1.1
-isort==5.13.2
-mypy==1.8.0
-types-six==1.17.0.20241205
-vermin==1.6.0

.github/workflows/style/requirements.txt

@@ -0,0 +1,7 @@
+black==23.12.1
+clingo==5.6.2
+flake8==7.0.0
+isort==5.13.2
+mypy==1.8.0
+types-six==1.16.21.9
+vermin==1.6.0

.github/workflows/unit_tests.yaml

@@ -16,34 +16,45 @@ jobs:
       matrix:
         os: [ubuntu-latest]
         python-version: ['3.7', '3.8', '3.9', '3.10', '3.11', '3.12']
+        concretizer: ['clingo']
         on_develop:
         - ${{ github.ref == 'refs/heads/develop' }}
         include:
+        - python-version: '3.11'
+          os: ubuntu-latest
+          concretizer: original
+          on_develop: ${{ github.ref == 'refs/heads/develop' }}
         - python-version: '3.6'
           os: ubuntu-20.04
+          concretizer: clingo
           on_develop: ${{ github.ref == 'refs/heads/develop' }}
         exclude:
         - python-version: '3.7'
           os: ubuntu-latest
+          concretizer: 'clingo'
           on_develop: false
         - python-version: '3.8'
           os: ubuntu-latest
+          concretizer: 'clingo'
           on_develop: false
         - python-version: '3.9'
           os: ubuntu-latest
+          concretizer: 'clingo'
           on_develop: false
         - python-version: '3.10'
           os: ubuntu-latest
+          concretizer: 'clingo'
           on_develop: false
         - python-version: '3.11'
           os: ubuntu-latest
+          concretizer: 'clingo'
           on_develop: false
 
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
       with:
         python-version: ${{ matrix.python-version }}
     - name: Install System packages
@@ -61,7 +72,7 @@ jobs:
       run: |
           # Need this for the git tests to succeed.
           git --version
-          . .github/workflows/bin/setup_git.sh
+          . .github/workflows/setup_git.sh
     - name: Bootstrap clingo
       if: ${{ matrix.concretizer == 'clingo' }}
       env:
@@ -74,25 +85,23 @@ jobs:
     - name: Run unit tests
       env:
           SPACK_PYTHON: python
+          SPACK_TEST_SOLVER: ${{ matrix.concretizer }}
           SPACK_TEST_PARALLEL: 2
           COVERAGE: true
-          COVERAGE_FILE: coverage/.coverage-${{ matrix.os }}-python${{ matrix.python-version }}
           UNIT_TEST_COVERAGE: ${{ matrix.python-version == '3.11' }}
       run: |
           share/spack/qa/run-unit-tests
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
       with:
-        name: coverage-${{ matrix.os }}-python${{ matrix.python-version }}
-        path: coverage
-        include-hidden-files: true
+        flags: unittests,linux,${{ matrix.concretizer }}
   # Test shell integration
   shell:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
       with:
         python-version: '3.11'
     - name: Install System packages
@@ -107,17 +116,15 @@ jobs:
       run: |
           # Need this for the git tests to succeed.
           git --version
-          . .github/workflows/bin/setup_git.sh
+          . .github/workflows/setup_git.sh
     - name: Run shell tests
       env:
           COVERAGE: true
       run: |
           share/spack/qa/run-shell-tests
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
       with:
-        name: coverage-shell
-        path: coverage
-        include-hidden-files: true
+        flags: shelltests,linux
 
   # Test RHEL8 UBI with platform Python. This job is run
   # only on PRs modifying core Spack
@@ -130,13 +137,13 @@ jobs:
           dnf install -y \
               bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
               make patch tcl unzip which xz
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
     - name: Setup repo and non-root user
       run: |
           git --version
           git config --global --add safe.directory /__w/spack/spack
           git fetch --unshallow
-          . .github/workflows/bin/setup_git.sh
+          . .github/workflows/setup_git.sh
           useradd spack-test
           chown -R spack-test .
     - name: Run unit tests
@@ -149,49 +156,45 @@ jobs:
   clingo-cffi:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
       with:
-        python-version: '3.13'
+        python-version: '3.11'
     - name: Install System packages
       run: |
           sudo apt-get -y update
-          sudo apt-get -y install coreutils gfortran graphviz gnupg2
+          sudo apt-get -y install coreutils cvs gfortran graphviz gnupg2 mercurial ninja-build kcov
     - name: Install Python packages
       run: |
-          pip install --upgrade pip setuptools pytest coverage[toml] pytest-cov clingo
+          pip install --upgrade pip setuptools pytest coverage[toml] pytest-cov clingo pytest-xdist
           pip install --upgrade flake8 "isort>=4.3.5" "mypy>=0.900" "click" "black"
+    - name: Setup git configuration
+      run: |
+          # Need this for the git tests to succeed.
+          git --version
+          . .github/workflows/setup_git.sh
     - name: Run unit tests (full suite with coverage)
       env:
           COVERAGE: true
-          COVERAGE_FILE: coverage/.coverage-clingo-cffi
+          SPACK_TEST_SOLVER: clingo
       run: |
-        . share/spack/setup-env.sh
-        spack bootstrap disable spack-install
-        spack bootstrap disable github-actions-v0.5
-        spack bootstrap disable github-actions-v0.6
-        spack bootstrap status
-        spack solve zlib
-        spack unit-test --verbose --cov --cov-config=pyproject.toml --cov-report=xml:coverage.xml lib/spack/spack/test/concretization/core.py
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
+          share/spack/qa/run-unit-tests
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d # @v2.1.0
       with:
-        name: coverage-clingo-cffi
-        path: coverage
-        include-hidden-files: true
+        flags: unittests,linux,clingo
   # Run unit tests on MacOS
   macos:
-    runs-on: ${{ matrix.os }}
+    runs-on: macos-latest
     strategy:
       matrix:
-        os: [macos-13, macos-14]
         python-version: ["3.11"]
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # @v2
       with:
         python-version: ${{ matrix.python-version }}
     - name: Install Python packages
@@ -200,52 +203,19 @@ jobs:
           pip install --upgrade pytest coverage[toml] pytest-xdist pytest-cov
     - name: Setup Homebrew packages
       run: |
-        brew install dash fish gcc gnupg kcov
+        brew install dash fish gcc gnupg2 kcov
     - name: Run unit tests
       env:
+        SPACK_TEST_SOLVER: clingo
         SPACK_TEST_PARALLEL: 4
-        COVERAGE_FILE: coverage/.coverage-${{ matrix.os }}-python${{ matrix.python-version }}
       run: |
         git --version
-        . .github/workflows/bin/setup_git.sh
+        . .github/workflows/setup_git.sh
         . share/spack/setup-env.sh
         $(which spack) bootstrap disable spack-install
         $(which spack) solve zlib
         common_args=(--dist loadfile --tx '4*popen//python=./bin/spack-tmpconfig python -u ./bin/spack python' -x)
         $(which spack) unit-test --verbose --cov --cov-config=pyproject.toml --cov-report=xml:coverage.xml "${common_args[@]}"
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
       with:
-        name: coverage-${{ matrix.os }}-python${{ matrix.python-version }}
-        path: coverage
-        include-hidden-files: true
-  # Run unit tests on Windows
-  windows:
-    defaults:
-      run:
-        shell:
-          powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}
-    runs-on: windows-latest
-    steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-      with:
-        python-version: 3.9
-    - name: Install Python packages
-      run: |
-          python -m pip install --upgrade pip pywin32 setuptools pytest-cov clingo
-    - name: Create local develop
-      run: |
-        ./.github/workflows/bin/setup_git.ps1
-    - name: Unit Test
-      env:
-        COVERAGE_FILE: coverage/.coverage-windows
-      run: |
-        spack unit-test -x --verbose --cov --cov-config=pyproject.toml
-        ./share/spack/qa/validate_last_exit.ps1
-    - uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882
-      with:
-        name: coverage-windows
-        path: coverage
-        include-hidden-files: true
+        flags: unittests,macos

.github/workflows/valid-style.yml

@@ -18,15 +18,15 @@ jobs:
   validate:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
       with:
         python-version: '3.11'
         cache: 'pip'
     - name: Install Python Packages
       run: |
         pip install --upgrade pip setuptools
-        pip install -r .github/workflows/requirements/style/requirements.txt
+        pip install -r .github/workflows/style/requirements.txt
     - name: vermin (Spack's Core)
       run: vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv lib/spack/spack/ lib/spack/llnl/ bin/
     - name: vermin (Repositories)
@@ -35,28 +35,27 @@ jobs:
   style:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
       with:
         python-version: '3.11'
         cache: 'pip'
     - name: Install Python packages
       run: |
         pip install --upgrade pip setuptools
-        pip install -r .github/workflows/requirements/style/requirements.txt
+        pip install -r .github/workflows/style/requirements.txt
     - name: Setup git configuration
       run: |
         # Need this for the git tests to succeed.
         git --version
-        . .github/workflows/bin/setup_git.sh
+        . .github/workflows/setup_git.sh
     - name: Run style tests
       run: |
           share/spack/qa/run-style-tests
   audit:
     uses: ./.github/workflows/audit.yaml
-    secrets: inherit
     with:
       with_coverage: ${{ inputs.with_coverage }}
       python_version: '3.11'
@@ -70,13 +69,13 @@ jobs:
           dnf install -y \
               bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
               make patch tcl unzip which xz
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # @v2
       - name: Setup repo and non-root user
         run: |
           git --version
           git config --global --add safe.directory /__w/spack/spack
           git fetch --unshallow
-          . .github/workflows/bin/setup_git.sh
+          . .github/workflows/setup_git.sh
           useradd spack-test
           chown -R spack-test .
       - name: Bootstrap Spack development environment
@@ -85,64 +84,5 @@ jobs:
           source share/spack/setup-env.sh
           spack debug report
           spack -d bootstrap now --dev
-          spack -d style -t black
+          spack style -t black
           spack unit-test -V
-  import-check:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: julia-actions/setup-julia@v2
-      with:
-        version: '1.10'
-    - uses: julia-actions/cache@v2
-
-    # PR: use the base of the PR as the old commit
-    - name: Checkout PR base commit
-      if: github.event_name == 'pull_request'
-      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        ref: ${{ github.event.pull_request.base.sha }}
-        path: old
-    # not a PR: use the previous commit as the old commit
-    - name: Checkout previous commit
-      if: github.event_name != 'pull_request'
-      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        fetch-depth: 2
-        path: old
-    - name: Checkout previous commit
-      if: github.event_name != 'pull_request'
-      run: git -C old reset --hard HEAD^
-
-    - name: Checkout new commit
-      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        path: new
-    - name: Install circular import checker
-      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        repository: haampie/circular-import-fighter
-        ref: 9f60f51bc7134e0be73f27623f1b0357d1718427
-        path: circular-import-fighter
-    - name: Install dependencies
-      working-directory: circular-import-fighter
-      run: make -j dependencies
-    - name: Import cycles before
-      working-directory: circular-import-fighter
-      run: make SPACK_ROOT=../old && cp solution solution.old
-    - name: Import cycles after
-      working-directory: circular-import-fighter
-      run: make clean-graph && make SPACK_ROOT=../new && cp solution solution.new
-    - name: Compare import cycles
-      working-directory: circular-import-fighter
-      run: |
-        edges_before="$(grep -oP 'edges to delete: \K\d+' solution.old)"
-        edges_after="$(grep -oP 'edges to delete: \K\d+' solution.new)"
-        if [ "$edges_after" -gt "$edges_before" ]; then
-          printf '\033[1;31mImport check failed: %s imports need to be deleted, ' "$edges_after"
-          printf 'previously this was %s\033[0m\n'  "$edges_before"
-          printf 'Compare \033[1;97m"Import cycles before"\033[0m and '
-          printf '\033[1;97m"Import cycles after"\033[0m to see problematic imports.\n'
-          exit 1
-        else
-          printf '\033[1;32mImport check passed: %s <= %s\033[0m\n' "$edges_after" "$edges_before"
-        fi

.github/workflows/windows_python.yml

@@ -0,0 +1,79 @@
+name: windows
+
+on:
+  workflow_call:
+
+concurrency:
+  group: windows-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
+  cancel-in-progress: true
+
+defaults:
+  run:
+    shell:
+     powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}
+jobs:
+  unit-tests:
+    runs-on: windows-latest
+    steps:
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
+      with:
+        python-version: 3.9
+    - name: Install Python packages
+      run: |
+          python -m pip install --upgrade pip pywin32 setuptools pytest-cov clingo
+    - name: Create local develop
+      run: |
+        ./.github/workflows/setup_git.ps1
+    - name: Unit Test
+      run: |
+        spack unit-test -x --verbose --cov --cov-config=pyproject.toml --ignore=lib/spack/spack/test/cmd
+        ./share/spack/qa/validate_last_exit.ps1
+        coverage combine -a
+        coverage xml
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
+      with:
+        flags: unittests,windows
+  unit-tests-cmd:
+    runs-on: windows-latest
+    steps:
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
+      with:
+        python-version: 3.9
+    - name: Install Python packages
+      run: |
+          python -m pip install --upgrade pip pywin32 setuptools coverage pytest-cov clingo
+    - name: Create local develop
+      run: |
+        ./.github/workflows/setup_git.ps1
+    - name: Command Unit Test
+      run: |
+        spack unit-test -x --verbose --cov --cov-config=pyproject.toml lib/spack/spack/test/cmd
+        ./share/spack/qa/validate_last_exit.ps1
+        coverage combine -a
+        coverage xml
+    - uses: codecov/codecov-action@eaaf4bedf32dbdc6b720b63067d99c4d77d6047d
+      with:
+        flags: unittests,windows
+  build-abseil:
+    runs-on: windows-latest
+    steps:
+    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c
+      with:
+        python-version: 3.9
+    - name: Install Python packages
+      run: |
+          python -m pip install --upgrade pip pywin32 setuptools coverage
+    - name: Build Test
+      run: |
+        spack compiler find
+        spack -d external find cmake ninja
+        spack -d install abseil-cpp

.readthedocs.yml

@@ -14,26 +14,3 @@ sphinx:
 python:
   install:
     - requirements: lib/spack/docs/requirements.txt
-
-search:
-  ranking:
-    spack.html: -10
-    spack.*.html: -10
-    llnl.html: -10
-    llnl.*.html: -10
-    _modules/*: -10
-    command_index.html: -9
-    basic_usage.html: 5
-    configuration.html: 5
-    config_yaml.html: 5
-    packages_yaml.html: 5
-    build_settings.html: 5
-    environments.html: 5
-    containers.html: 5
-    mirrors.html: 5
-    module_file_support.html: 5
-    repositories.html: 5
-    binary_caches.html: 5
-    chain.html: 5
-    pipelines.html: 5
-    packaging_guide.html: 5

CHANGELOG.md

@@ -1,440 +1,3 @@
-# v0.22.2 (2024-09-21)
-
-## Bugfixes
-- Forward compatibility with Spack 0.23 packages with language dependencies (#45205, #45191)
-- Forward compatibility with `urllib` from Python 3.12.6+ (#46453, #46483)
-- Bump vendored `archspec` for better aarch64 support (#45721, #46445)
-- Support macOS Sequoia (#45018, #45127)
-- Fix regression in `{variants.X}` and `{variants.X.value}` format strings (#46206)
-- Ensure shell escaping of environment variable values in load and activate commands (#42780)
-- Fix an issue where `spec[pkg]` considers specs outside the current DAG (#45090)
-- Do not halt concretization on unknown variants in externals (#45326)
-- Improve validation of `develop` config section (#46485)
-- Explicitly disable `ccache` if turned off in config, to avoid cache pollution (#45275)
-- Improve backwards compatibility in `include_concrete` (#45766)
-- Fix issue where package tags were sometimes repeated (#45160)
-- Make `setup-env.sh` "sourced only" by dropping execution bits (#45641)
-- Make certain source/binary fetch errors recoverable instead of a hard error (#45683)
-- Remove debug statements in package hash computation (#45235)
-- Remove redundant clingo warnings (#45269)
-- Remove hard-coded layout version (#45645)
-- Do not initialize previous store state in `use_store` (#45268)
-- Docs improvements (#46475)
-
-## Package updates
-- `chapel` major update (#42197, #44931, #45304)
-
-# v0.22.1 (2024-07-04)
-
-## Bugfixes
-- Fix reuse of externals on Linux (#44316)
-- Ensure parent gcc-runtime version >= child (#44834, #44870)
-- Ensure the latest gcc-runtime is rpath'ed when multiple exist among link deps (#44219)
-- Improve version detection of glibc (#44154)
-- Improve heuristics for solver (#44893, #44976, #45023)
-- Make strong preferences override reuse (#44373)
-- Reduce verbosity when C compiler is missing (#44182)
-- Make missing ccache executable an error when required (#44740)
-- Make every environment view containing `python` a `venv` (#44382)
-- Fix external detection for compilers with os but no target (#44156)
-- Fix version optimization for roots (#44272)
-- Handle common implementations of pagination of tags in OCI build caches (#43136)
-- Apply fetched patches to develop specs (#44950)
-- Avoid Windows wrappers for filesystem utilities on non-Windows (#44126)
-- Fix issue with long filenames in build caches on Windows (#43851)
-- Fix formatting issue in `spack audit` (#45045)
-- CI fixes (#44582, #43965, #43967, #44279, #44213)
-
-## Package updates
-- protobuf: fix 3.4:3.21 patch checksum (#44443)
-- protobuf: update hash for patch needed when="@3.4:3.21" (#44210)
-- git: bump v2.39 to 2.45; deprecate unsafe versions (#44248)
-- gcc: use -rpath {rpath_dir} not -rpath={rpath dir} (#44315)
-- Remove mesa18 and libosmesa (#44264)
-- Enforce consistency of `gl` providers (#44307)
-- Require libiconv for iconv (#44335, #45026).
-  Notice that glibc/musl also provide iconv, but are not guaranteed to be
-  complete. Set `packages:iconv:require:[glibc]` to restore the old behavior.
-- py-matplotlib: qualify when to do a post install (#44191)
-- rust: fix v1.78.0 instructions (#44127)
-- suite-sparse: improve setting of the `libs` property (#44214)
-- netlib-lapack: provide blas and lapack together (#44981)
-
-# v0.22.0 (2024-05-12)
-
-`v0.22.0` is a major feature release.
-
-## Features in this release
-
-1. **Compiler dependencies**
-
-    We are in the process of making compilers proper dependencies in Spack, and a number
-    of changes in `v0.22` support that effort. You may notice nodes in your dependency
-    graphs for compiler runtime libraries like `gcc-runtime` or `libgfortran`, and you
-    may notice that Spack graphs now include `libc`. We've also begun moving compiler
-    configuration from `compilers.yaml` to `packages.yaml` to make it consistent with
-    other externals. We are trying to do this with the least disruption possible, so
-    your existing `compilers.yaml` files should still work. We expect to be done with
-    this transition by the `v0.23` release in November.
-
-    * #41104: Packages compiled with `%gcc` on Linux, macOS and FreeBSD now depend on a
-      new package `gcc-runtime`, which contains a copy of the shared compiler runtime
-      libraries. This enables gcc runtime libraries to be installed and relocated when
-      using a build cache. When building minimal Spack-generated container images it is
-      no longer necessary to install libgfortran, libgomp etc. using the system package
-      manager.
-
-    * #42062: Packages compiled with `%oneapi` now depend on a new package
-      `intel-oneapi-runtime`. This is similar to `gcc-runtime`, and the runtimes can
-      provide virtuals and compilers can inject dependencies on virtuals into compiled
-      packages. This allows us to model library soname compatibility and allows
-      compilers like `%oneapi` to provide virtuals like `sycl` (which can also be
-      provided by standalone libraries). Note that until we have an agreement in place
-      with intel, Intel packages are marked `redistribute(source=False, binary=False)`
-      and must be downloaded outside of Spack.
-
-    * #43272: changes to the optimization criteria of the solver improve the hit-rate of
-      buildcaches by a fair amount. The solver more relaxed compatibility rules and will
-      not try to strictly match compilers or targets of reused specs. Users can still
-      enforce the previous strict behavior with `require:` sections in `packages.yaml`.
-      Note that to enforce correct linking, Spack will *not* reuse old `%gcc` and
-      `%oneapi` specs that do not have the runtime libraries as a dependency.
-
-    * #43539: Spack will reuse specs built with compilers that are *not* explicitly
-      configured in `compilers.yaml`. Because we can now keep runtime libraries in build
-      cache, we do not require you to also have a local configured compiler to *use* the
-      runtime libraries. This improves reuse in buildcaches and avoids conflicts with OS
-      updates that happen underneath Spack.
-
-    * #43190: binary compatibility on `linux` is now based on the `libc` version,
-      instead of on the `os` tag. Spack builds now detect the host `libc` (`glibc` or
-      `musl`) and add it as an implicit external node in the dependency graph. Binaries
-      with a `libc` with the same name and a version less than or equal to that of the
-      detected `libc` can be reused. This is only on `linux`, not `macos` or `Windows`.
-
-    * #43464: each package that can provide a compiler is now detectable using `spack
-      external find`. External packages defining compiler paths are effectively used as
-      compilers, and `spack external find -t compiler` can be used as a substitute for
-      `spack compiler find`. More details on this transition are in
-      [the docs](https://spack.readthedocs.io/en/latest/getting_started.html#manual-compiler-configuration)
-
-2. **Improved `spack find` UI for Environments**
-
-   If you're working in an enviroment, you likely care about:
-
-   * What are the roots
-   * Which ones are installed / not installed
-   * What's been added that still needs to be concretized
-
-    We've tweaked `spack find` in environments to show this information much more
-    clearly. Installation status is shown next to each root, so you can see what is
-    installed. Roots are also shown in bold in the list of installed packages. There is
-    also a new option for `spack find -r` / `--only-roots` that will only show env
-    roots, if you don't want to look at all the installed specs.
-
-    More details in #42334.
-
-3. **Improved command-line string quoting**
-
-   We are making some breaking changes to how Spack parses specs on the CLI in order to
-   respect shell quoting instead of trying to fight it. If you (sadly) had to write
-   something like this on the command line:
-
-    ```
-    spack install zlib cflags=\"-O2 -g\"
-    ```
-
-    That will now result in an error, but you can now write what you probably expected
-    to work in the first place:
-
-    ```
-    spack install zlib cflags="-O2 -g"
-    ```
-
-    Quoted can also now include special characters, so you can supply flags like:
-
-    ```
-    spack intall zlib ldflags='-Wl,-rpath=$ORIGIN/_libs'
-    ```
-
-    To reduce ambiguity in parsing, we now require that you *not* put spaces around `=`
-    and `==` when for flags or variants. This would not have broken before but will now
-    result in an error:
-
-    ```
-    spack install zlib cflags = "-O2 -g"
-    ```
-
-    More details and discussion in #30634.
-
-4. **Revert default `spack install` behavior to `--reuse`**
-
-   We changed the default concretizer behavior from `--reuse` to `--reuse-deps` in
-   #30990 (in `v0.20`), which meant that *every* `spack install` invocation would
-   attempt to build a new version of the requested package / any environment roots.
-   While this is a common ask for *upgrading* and for *developer* workflows, we don't
-   think it should be the default for a package manager.
-
-   We are going to try to stick to this policy:
-   1. Prioritize reuse and build as little as possible by default.
-   2. Only upgrade or install duplicates if they are explicitly asked for, or if there
-      is a known security issue that necessitates an upgrade.
-
-   With the install command you now have three options:
-
-   * `--reuse` (default): reuse as many existing installations as possible.
-   * `--reuse-deps` / `--fresh-roots`: upgrade (freshen) roots but reuse dependencies if possible.
-   * `--fresh`: install fresh versions of requested packages (roots) and their dependencies.
-
-   We've also introduced `--fresh-roots` as an alias for `--reuse-deps` to make it more clear
-   that it may give you fresh versions. More details in #41302 and #43988.
-
-5. **More control over reused specs**
-
-   You can now control which packages to reuse and how. There is a new
-   `concretizer:reuse` config option, which accepts the following properties:
-
-   - `roots`: `true` to reuse roots, `false` to reuse just dependencies
-   - `exclude`: list of constraints used to select which specs *not* to reuse
-   - `include`: list of constraints used to select which specs *to* reuse
-   - `from`: list of sources for reused specs (some combination of `local`,
-     `buildcache`, or `external`)
-
-   For example, to reuse only specs compiled with GCC, you could write:
-
-   ```yaml
-   concretizer:
-      reuse:
-        roots: true
-        include:
-        - "%gcc"
-   ```
-
-   Or, if `openmpi` must be used from externals, and it must be the only external used:
-
-   ```yaml
-   concretizer:
-     reuse:
-       roots: true
-       from:
-       - type: local
-         exclude: ["openmpi"]
-       - type: buildcache
-         exclude: ["openmpi"]
-       - type: external
-         include: ["openmpi"]
-   ```
-
-6. **New `redistribute()` directive**
-
-   Some packages can't be redistributed in source or binary form. We need an explicit
-   way to say that in a package.
-
-   Now there is a `redistribute()` directive so that package authors can write:
-
-   ```python
-   class MyPackage(Package):
-       redistribute(source=False, binary=False)
-   ```
-
-   Like other directives, this works with `when=`:
-
-   ```python
-   class MyPackage(Package):
-       # 12.0 and higher are proprietary
-       redistribute(source=False, binary=False, when="@12.0:")
-
-       # can't redistribute when we depend on some proprietary dependency
-       redistribute(source=False, binary=False, when="^proprietary-dependency")
-   ```
-
-    More in #20185.
-
-7. **New `conflict:` and `prefer:` syntax for package preferences**
-
-   Previously, you could express conflicts and preferences in `packages.yaml` through
-   some contortions with `require:`:
-
-    ```yaml
-    packages:
-      zlib-ng:
-        require:
-        - one_of: ["%clang", "@:"]   # conflict on %clang
-        - any_of: ["+shared", "@:"]  # strong preference for +shared
-    ```
-
-    You can now use `require:` and `prefer:` for a much more readable configuration:
-
-    ```yaml
-    packages:
-      zlib-ng:
-        conflict:
-        - "%clang"
-        prefer:
-        - "+shared"
-    ```
-
-    See [the documentation](https://spack.readthedocs.io/en/latest/packages_yaml.html#conflicts-and-strong-preferences)
-    and #41832 for more details.
-
-8. **`include_concrete` in environments**
-
-   You may want to build on the *concrete* contents of another environment without
-   changing that environment.  You can now include the concrete specs from another
-   environment's `spack.lock` with `include_concrete`:
-
-   ```yaml
-      spack:
-        specs: []
-        concretizer:
-            unify: true
-        include_concrete:
-        - /path/to/environment1
-        - /path/to/environment2
-   ```
-
-   Now, when *this* environment is concretized, it will bring in the already concrete
-   specs from `environment1` and `environment2`, and build on top of them without
-   changing them. This is useful if you have phased deployments, where old deployments
-   should not be modified but you want to use as many of them as possible. More details
-   in #33768.
-
-9. **`python-venv` isolation**
-
-   Spack has unique requirements for Python because it:
-    1. installs every package in its own independent directory, and
-    2. allows users to register *external* python installations.
-
-   External installations may contain their own installed packages that can interfere
-   with Spack installations, and some distributions (Debian and Ubuntu) even change the
-   `sysconfig` in ways that alter the installation layout of installed Python packages
-   (e.g., with the addition of a `/local` prefix on Debian or Ubuntu). To isolate Spack
-   from these and other issues, we now insert a small `python-venv` package in between
-   `python` and packages that need to install Python code. This isolates Spack's build
-   environment, isolates Spack from any issues with an external python, and resolves a
-   large number of issues we've had with Python installations.
-
-   See #40773 for further details.
-
-## New commands, options, and directives
-
-* Allow packages to be pushed to build cache after install from source (#42423)
-* `spack develop`: stage build artifacts in same root as non-dev builds #41373
-  * Don't delete `spack develop` build artifacts after install (#43424)
-* `spack find`: add options for local/upstream only (#42999)
-* `spack logs`: print log files for packages (either partially built or installed) (#42202)
-* `patch`: support reversing patches (#43040)
-* `develop`: Add -b/--build-directory option to set build_directory package attribute (#39606)
-* `spack list`: add `--namesapce` / `--repo` option (#41948)
-* directives: add `checked_by` field to `license()`, add some license checks
-* `spack gc`: add options for environments and build dependencies (#41731)
-* Add `--create` to `spack env activate` (#40896)
-
-## Performance improvements
-
-* environment.py: fix excessive re-reads (#43746)
-* ruamel yaml: fix quadratic complexity bug  (#43745)
-* Refactor to improve `spec format` speed (#43712)
-* Do not acquire a write lock on the env post install if no views (#43505)
-* asp.py: fewer calls to `spec.copy()` (#43715)
-* spec.py: early return in `__str__`
-* avoid `jinja2` import at startup unless needed (#43237)
-
-## Other new features of note
-
-* `archspec`: update to `v0.2.4`: support for Windows, bugfixes for `neoverse-v1` and
-  `neoverse-v2` detection.
-* `spack config get`/`blame`: with no args, show entire config
-* `spack env create <env>`: dir if dir-like (#44024)
-* ASP-based solver: update os compatibility for macOS (#43862)
-* Add handling of custom ssl certs in urllib ops (#42953)
-* Add ability to rename environments (#43296)
-* Add config option and compiler support to reuse across OS's (#42693)
-* Support for prereleases (#43140)
-* Only reuse externals when configured (#41707)
-* Environments: Add support for including views (#42250)
-
-## Binary caches
-* Build cache: make signed/unsigned a mirror property (#41507)
-* tools stack
-
-## Removals, deprecations, and syntax changes
-* remove `dpcpp` compiler and package (#43418)
-* spack load: remove --only argument (#42120)
-
-## Notable Bugfixes
-* repo.py: drop deleted packages from provider cache (#43779)
-* Allow `+` in module file names (#41999)
-* `cmd/python`: use runpy to allow multiprocessing in scripts (#41789)
-* Show extension commands with spack -h (#41726)
-* Support environment variable expansion inside module projections (#42917)
-* Alert user to failed concretizations (#42655)
-* shell: fix zsh color formatting for PS1 in environments (#39497)
-* spack mirror create --all: include patches (#41579)
-
-## Spack community stats
-
-* 7,994 total packages; 525 since `v0.21.0`
-    * 178 new Python packages, 5 new R packages
-* 358 people contributed to this release
-    * 344 committers to packages
-    * 45 committers to core
-
-# v0.21.3 (2024-10-02)
-
-## Bugfixes
-- Forward compatibility with Spack 0.23 packages with language dependencies (#45205, #45191)
-- Forward compatibility with `urllib` from Python 3.12.6+ (#46453, #46483)
-- Bump `archspec` to 0.2.5-dev for better aarch64 and Windows support (#42854, #44005,
-  #45721, #46445)
-- Support macOS Sequoia (#45018, #45127, #43862)
-- CI and test maintenance (#42909, #42728, #46711, #41943, #43363)
-
-# v0.21.2 (2024-03-01)
-
-## Bugfixes
-
-- Containerize: accommodate nested or pre-existing spack-env paths (#41558)
-- Fix setup-env script, when going back and forth between instances (#40924)
-- Fix using fully-qualified namespaces from root specs (#41957)
-- Fix a bug when a required provider is requested for multiple virtuals (#42088)
-- OCI buildcaches:
-  - only push in parallel when forking (#42143)
-  - use pickleable errors (#42160)
-- Fix using sticky variants in externals (#42253)
-- Fix a rare issue with conditional requirements and multi-valued variants (#42566)
-
-## Package updates
-- rust: add v1.75, rework a few variants (#41161,#41903)
-- py-transformers: add v4.35.2 (#41266)
-- mgard: fix OpenMP on AppleClang (#42933)
-
-# v0.21.1 (2024-01-11)
-
-## New features
-- Add support for reading buildcaches created by Spack v0.22 (#41773)
-
-## Bugfixes
-
-- spack graph: fix coloring with environments (#41240)
-- spack info: sort variants in --variants-by-name (#41389)
-- Spec.format: error on old style format strings (#41934)
-- ASP-based solver: 
-  - fix infinite recursion when computing concretization errors (#41061)
-  - don't error for type mismatch on preferences (#41138)
-  - don't emit spurious debug output (#41218)
-- Improve the error message for deprecated preferences (#41075)
-- Fix MSVC preview version breaking clingo build on Windows (#41185)
-- Fix multi-word aliases (#41126)
-- Add a warning for unconfigured compiler (#41213)
-- environment: fix an issue with deconcretization/reconcretization of specs (#41294)
-- buildcache: don't error if a patch is missing, when installing from binaries (#41986)
-- Multiple improvements to unit-tests (#41215,#41369,#41495,#41359,#41361,#41345,#41342,#41308,#41226)
-
-## Package updates
-- root: add a webgui patch to address security issue (#41404)
-- BerkeleyGW: update source urls (#38218)
-
 # v0.21.0 (2023-11-11)
 
 `v0.21.0` is a major feature release.

README.md

@@ -32,7 +32,7 @@
 
 Spack is a multi-platform package manager that builds and installs
 multiple versions and configurations of software. It works on Linux,
-macOS, Windows, and many supercomputers. Spack is non-destructive: installing a
+macOS, and many supercomputers. Spack is non-destructive: installing a
 new version of a package does not break existing installations, so many
 configurations of the same package can coexist.
 
@@ -46,18 +46,13 @@ See the
 [Feature Overview](https://spack.readthedocs.io/en/latest/features.html)
 for examples and highlights.
 
-To install spack and your first package, make sure you have Python & Git.
+To install spack and your first package, make sure you have Python.
 Then:
 
-    $ git clone -c feature.manyFiles=true --depth=2 https://github.com/spack/spack.git
+    $ git clone -c feature.manyFiles=true https://github.com/spack/spack.git
     $ cd spack/bin
     $ ./spack install zlib
 
-> [!TIP]
-> `-c feature.manyFiles=true` improves git's performance on repositories with 1,000+ files.
->
-> `--depth=2` prunes the git history to reduce the size of the Spack installation.
-
 Documentation
 ----------------
 
@@ -70,7 +65,7 @@ Tutorial
 ----------------
 
 We maintain a
-[**hands-on tutorial**](https://spack-tutorial.readthedocs.io/).
+[**hands-on tutorial**](https://spack.readthedocs.io/en/latest/tutorial.html).
 It covers basic to advanced usage, packaging, developer features, and large HPC
 deployments.  You can do all of the exercises on your own laptop using a
 Docker container.
@@ -93,7 +88,7 @@ Resources:
   [bridged](https://github.com/matrix-org/matrix-appservice-slack#matrix-appservice-slack) to Slack.
 * [**Github Discussions**](https://github.com/spack/spack/discussions):
   for Q&A and discussions. Note the pinned discussions for announcements.
-* **X**: [@spackpm](https://twitter.com/spackpm). Be sure to
+* **Twitter**: [@spackpm](https://twitter.com/spackpm). Be sure to
   `@mention` us!
 * **Mailing list**: [groups.google.com/d/forum/spack](https://groups.google.com/d/forum/spack):
   only for announcements. Please use other venues for discussions.

bin/spack-python

@@ -22,4 +22,4 @@
 #
 # This is compatible across platforms.
 #
-exec spack python "$@"
+exec /usr/bin/env spack python "$@"

bin/spack.bat

@@ -188,27 +188,25 @@ if NOT "%_sp_args%"=="%_sp_args:--help=%" (
 goto :end_switch
 
 :case_load
-if NOT defined _sp_args (
-   exit /B 0
-)
-
-:: If args contain --bat, or -h/--help: just execute.
-if NOT "%_sp_args%"=="%_sp_args:--help=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args:-h=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args:--bat=%" (
-    goto :default_case
-) else if NOT "%_sp_args%"=="%_sp_args:--list=%" (
-    goto :default_case
+:: If args contain --sh, --csh, or -h/--help: just execute.
+if defined _sp_args (
+    if NOT "%_sp_args%"=="%_sp_args:--help=%" (
+        goto :default_case
+    ) else if NOT "%_sp_args%"=="%_sp_args:-h=%" (
+        goto :default_case
+    ) else if NOT "%_sp_args%"=="%_sp_args:--bat=%" (
+        goto :default_case
+    )
 )
 
 for /f "tokens=* USEBACKQ" %%I in (
-    `python "%spack%" %_sp_flags% %_sp_subcommand% --bat %_sp_args%`
-    ) do %%I
+    `python "%spack%" %_sp_flags% %_sp_subcommand% --bat %_sp_args%`) do %%I
 
 goto :end_switch
 
+:case_unload
+goto :case_load
+
 :default_case
 python "%spack%" %_sp_flags% %_sp_subcommand% %_sp_args%
 goto :end_switch

bin/spack.ps1

@@ -144,5 +144,3 @@ switch($SpackSubCommand)
     "unload" {Invoke-SpackLoad}
     default  {python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs}
 }
-
-exit $LASTEXITCODE

bin/spack_cmd.bat

@@ -1,11 +1,71 @@
 @ECHO OFF
+setlocal EnableDelayedExpansion
 :: (c) 2021 Lawrence Livermore National Laboratory
 :: To use this file independently of Spack's installer, execute this script in its directory, or add the
 :: associated bin directory to your PATH. Invoke to launch Spack Shell.
 ::
 :: source_dir/spack/bin/spack_cmd.bat
 ::
+pushd %~dp0..
+set SPACK_ROOT=%CD%
+pushd %CD%\..
+set spackinstdir=%CD%
+popd
 
-call "%~dp0..\share\spack\setup-env.bat"
-pushd %SPACK_ROOT%
-%comspec% /K
+
+:: Check if Python is on the PATH
+if not defined python_pf_ver (
+(for /f "delims=" %%F in ('where python.exe') do (
+                                                    set "python_pf_ver=%%F"
+                                                    goto :found_python
+                                                  ) ) 2> NUL
+)
+:found_python
+if not defined python_pf_ver (
+    :: If not, look for Python from the Spack installer
+    :get_builtin
+    (for /f "tokens=*" %%g in ('dir /b /a:d "!spackinstdir!\Python*"') do (
+        set "python_ver=%%g")) 2> NUL
+
+    if not defined python_ver (
+        echo Python was not found on your system.
+        echo Please install Python or add Python to your PATH.
+    ) else (
+        set "py_path=!spackinstdir!\!python_ver!"
+        set "py_exe=!py_path!\python.exe"
+    )
+    goto :exitpoint
+) else (
+    :: Python is already on the path
+    set "py_exe=!python_pf_ver!"
+    (for /F "tokens=* USEBACKQ" %%F in (
+        `"!py_exe!" --version`) do (set "output=%%F")) 2>NUL
+    if not "!output:Microsoft Store=!"=="!output!" goto :get_builtin
+    goto :exitpoint
+)
+:exitpoint
+
+set "PATH=%SPACK_ROOT%\bin\;%PATH%"
+if defined py_path (
+    set "PATH=%py_path%;%PATH%"
+)
+
+if defined py_exe (
+    "%py_exe%" "%SPACK_ROOT%\bin\haspywin.py"
+)
+
+set "EDITOR=notepad"
+
+DOSKEY spacktivate=spack env activate $*
+
+@echo **********************************************************************
+@echo ** Spack Package Manager
+@echo **********************************************************************
+
+IF "%1"=="" GOTO CONTINUE
+set
+GOTO:EOF
+
+:continue
+set PROMPT=[spack] %PROMPT%
+%comspec% /k

etc/spack/defaults/bootstrap.yaml

@@ -9,15 +9,15 @@ bootstrap:
   # may not be able to bootstrap all the software that Spack needs,
   # depending on its type.
   sources:
-  - name: github-actions-v0.6
-    metadata: $spack/share/spack/bootstrap/github-actions-v0.6
-  - name: github-actions-v0.5
+  - name: 'github-actions-v0.5'
     metadata: $spack/share/spack/bootstrap/github-actions-v0.5
-  - name: spack-install
+  - name: 'github-actions-v0.4'
+    metadata: $spack/share/spack/bootstrap/github-actions-v0.4
+  - name: 'spack-install'
     metadata: $spack/share/spack/bootstrap/spack-install
   trusted:
     # By default we trust bootstrapping from sources and from binaries
     # produced on Github via the workflow
-    github-actions-v0.6: true
     github-actions-v0.5: true
+    github-actions-v0.4: true
     spack-install: true

etc/spack/defaults/concretizer.yaml

@@ -15,7 +15,7 @@ concretizer:
   # as possible, rather than building. If `false`, we'll always give you a fresh
   # concretization. If `dependencies`, we'll only reuse dependencies but
   # give you a fresh concretization for your root specs.
-  reuse: true
+  reuse: dependencies
   # Options that tune which targets are considered for concretization. The
   # concretization process is very sensitive to the number targets, and the time
   # needed to reach a solution increases noticeably with the number of targets
@@ -39,27 +39,6 @@ concretizer:
   # Option to deal with possible duplicate nodes (i.e. different nodes from the same package) in the DAG.
   duplicates:
     # "none": allows a single node for any package in the DAG.
-    # "minimal": allows the duplication of 'build-tools' nodes only
-    # (e.g. py-setuptools, cmake etc.)
+    # "minimal": allows the duplication of 'build-tools' nodes only (e.g. py-setuptools, cmake etc.)
     # "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
     strategy: minimal
-  # Option to specify compatibility between operating systems for reuse of compilers and packages
-  # Specified as a key: [list] where the key is the os that is being targeted, and the list contains the OS's
-  # it can reuse. Note this is a directional compatibility so mutual compatibility between two OS's
-  # requires two entries i.e. os_compatible: {sonoma: [monterey], monterey: [sonoma]}
-  os_compatible: {}
-
-  # Option to specify whether to support splicing. Splicing allows for
-  # the relinking of concrete package dependencies in order to better
-  # reuse already built packages with ABI compatible dependencies
-  splice:
-    explicit: []
-    automatic: false
-  # Maximum time, in seconds, allowed for the 'solve' phase. If set to 0, there is no time limit.
-  timeout: 0
-  # If set to true, exceeding the timeout will always result in a concretization error. If false,
-  # the best (suboptimal) model computed before the timeout is used.
-  #
-  # Setting this to false yields unreproducible results, so we advise to use that value only
-  # for debugging purposes (e.g. check which constraints can help Spack concretize faster).
-  error_on_timeout: true

etc/spack/defaults/config.yaml

@@ -101,12 +101,6 @@ config:
   verify_ssl: true
 
 
-  # This is where custom certs for proxy/firewall are stored.
-  # It can be a path or environment variable. To match ssl env configuration
-  # the default is the environment variable SSL_CERT_FILE
-  ssl_certs: $SSL_CERT_FILE
-
-
   # Suppress gpg warnings from binary package verification
   # Only suppresses warnings, gpg failure will still fail the install
   # Potential rationale to set True: users have already explicitly trusted the
@@ -115,6 +109,12 @@ config:
   suppress_gpg_warnings: false
 
 
+  # If set to true, Spack will attempt to build any compiler on the spec
+  # that is not already available. If set to False, Spack will only use
+  # compilers already configured in compilers.yaml
+  install_missing_compilers: false
+
+
   # If set to true, Spack will always check checksums after downloading
   # archives. If false, Spack skips the checksum step.
   checksum: true
@@ -164,6 +164,23 @@ config:
   # If set to true, Spack will use ccache to cache C compiles.
   ccache: false
 
+
+  # The concretization algorithm to use in Spack. Options are:
+  #
+  #   'clingo': Uses a logic solver under the hood to solve DAGs with full
+  #       backtracking and optimization for user preferences. Spack will
+  #       try to bootstrap the logic solver, if not already available.
+  #
+  #   'original': Spack's original greedy, fixed-point concretizer. This
+  #       algorithm can make decisions too early and will not backtrack
+  #       sufficiently for many specs. This will soon be deprecated in
+  #       favor of clingo.
+  #
+  # See `concretizer.yaml` for more settings you can fine-tune when
+  # using clingo.
+  concretizer: clingo
+
+
   # How long to wait to lock the Spack installation database. This lock is used
   # when Spack needs to manage its own package metadata and all operations are
   # expected to complete within the default time limit. The timeout should

etc/spack/defaults/cray/modules.yaml

@@ -0,0 +1,16 @@
+# -------------------------------------------------------------------------
+# This is the default configuration for Spack's module file generation.
+#
+# Settings here are versioned with Spack and are intended to provide
+# sensible defaults out of the box. Spack maintainers should edit this
+# file to keep it current.
+#
+# Users can override these settings by editing the following files.
+#
+# Per-spack-instance settings (overrides defaults):
+#   $SPACK_ROOT/etc/spack/modules.yaml
+#
+# Per-user settings (overrides default and site settings):
+#   ~/.spack/modules.yaml
+# -------------------------------------------------------------------------
+modules: {}

etc/spack/defaults/darwin/packages.yaml

@@ -19,6 +19,7 @@ packages:
     - apple-clang
     - clang
     - gcc
+    - intel
     providers:
       elf: [libelf]
       fuse: [macfuse]

etc/spack/defaults/packages.yaml

@@ -15,20 +15,15 @@
 # -------------------------------------------------------------------------
 packages:
   all:
-    compiler: [gcc, clang, oneapi, xl, nag, fj, aocc]
+    compiler: [gcc, intel, pgi, clang, xl, nag, fj, aocc]
     providers:
       awk: [gawk]
-      armci: [armcimpi]
       blas: [openblas, amdblis]
-      c: [gcc]
-      cxx: [gcc]
       D: [ldc]
       daal: [intel-oneapi-daal]
       elf: [elfutils]
       fftw-api: [fftw, amdfftw]
       flame: [libflame, amdlibflame]
-      fortran: [gcc]
-      fortran-rt: [gcc-runtime, intel-oneapi-runtime]
       fuse: [libfuse]
       gl: [glx, osmesa]
       glu: [mesa-glu, openglu]
@@ -39,11 +34,9 @@ packages:
       java: [openjdk, jdk, ibm-java]
       jpeg: [libjpeg-turbo, libjpeg]
       lapack: [openblas, amdlibflame]
-      libc: [glibc, musl]
-      libgfortran: [gcc-runtime]
-      libglx: [mesa+glx]
-      libifcore: [intel-oneapi-runtime]
+      libglx: [mesa+glx, mesa18+glx]
       libllvm: [llvm]
+      libosmesa: [mesa+osmesa, mesa18+osmesa]
       lua-lang: [lua, lua-luajit-openresty, lua-luajit]
       luajit: [lua-luajit-openresty, lua-luajit]
       mariadb-client: [mariadb-c-client, mariadb]
@@ -64,7 +57,6 @@ packages:
       tbb: [intel-tbb]
       unwind: [libunwind]
       uuid: [util-linux-uuid, libuuid]
-      wasi-sdk: [wasi-sdk-prebuilt]
       xxd: [xxd-standalone, vim]
       yacc: [bison, byacc]
       ziglang: [zig]
@@ -72,15 +64,3 @@ packages:
     permissions:
       read: world
       write: user
-  cray-mpich:
-    buildable: false
-  cray-mvapich2:
-    buildable: false
-  egl:
-    buildable: false
-  fujitsu-mpi:
-    buildable: false
-  hpcx-mpi:
-    buildable: false
-  spectrum-mpi:
-    buildable: false

etc/spack/defaults/windows/config.yaml

@@ -1,5 +1,6 @@
 config:
   locks: false
+  concretizer: clingo
   build_stage::
     - '$spack/.staging'
   stage_name: '{name}-{version}-{hash:7}'

lib/spack/docs/_templates/layout.html

@@ -1,12 +0,0 @@
-{% extends "!layout.html" %}
-
-{%- block extrahead %} 
-  <!-- Google tag (gtag.js) -->
-  <script async src="https://www.googletagmanager.com/gtag/js?id=G-S0PQ7WV75K"></script>
-  <script>
-    window.dataLayer = window.dataLayer || [];
-    function gtag(){dataLayer.push(arguments);}
-    gtag('js', new Date());
-    gtag('config', 'G-S0PQ7WV75K');
-  </script>
-{% endblock %}

lib/spack/docs/basic_usage.rst

@@ -865,7 +865,7 @@ There are several different ways to use Spack packages once you have
 installed them. As you've seen, spack packages are installed into long
 paths with hashes, and you need a way to get them into your path. The
 easiest way is to use :ref:`spack load <cmd-spack-load>`, which is
-described in this section.
+described in the next section.
 
 Some more advanced ways to use Spack packages include:
 
@@ -959,86 +959,7 @@ use ``spack find --loaded``.
 You can also use ``spack load --list`` to get the same output, but it
 does not have the full set of query options that ``spack find`` offers.
 
-We'll learn more about Spack's spec syntax in :ref:`a later section <sec-specs>`.
-
-
-.. _extensions:
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Python packages and virtual environments
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Spack can install a large number of Python packages. Their names are
-typically prefixed with ``py-``. Installing and using them is no
-different from any other package:
-
-.. code-block:: console
-
-   $ spack install py-numpy
-   $ spack load py-numpy
-   $ python3
-   >>> import numpy
-
-The ``spack load`` command sets the ``PATH`` variable so that the right Python
-executable is used, and makes sure that ``numpy`` and its dependencies can be
-located in the ``PYTHONPATH``.
-
-Spack is different from other Python package managers in that it installs
-every package into its *own* prefix. This is in contrast to ``pip``, which
-installs all packages into the same prefix, be it in a virtual environment
-or not.
-
-For many users, **virtual environments** are more convenient than repeated
-``spack load`` commands, particularly when working with multiple Python
-packages. Fortunately Spack supports environments itself, which together
-with a view are no different from Python virtual environments.
-
-The recommended way of working with Python extensions such as ``py-numpy``
-is through :ref:`Environments <environments>`. The following example creates
-a Spack environment with ``numpy`` in the current working directory. It also
-puts a filesystem view in ``./view``, which is a more traditional combined
-prefix for all packages in the environment.
-
-.. code-block:: console
-
-   $ spack env create --with-view view --dir .
-   $ spack -e . add py-numpy
-   $ spack -e . concretize
-   $ spack -e . install
-
-Now you can activate the environment and start using the packages:
-
-.. code-block:: console
-
-   $ spack env activate .
-   $ python3
-   >>> import numpy
-
-The environment view is also a virtual environment, which is useful if you are
-sharing the environment with others who are unfamiliar with Spack. They can
-either use the Python executable directly:
-
-.. code-block:: console
-
-   $ ./view/bin/python3
-   >>> import numpy
-
-or use the activation script:
-
-.. code-block:: console
-
-   $ source ./view/bin/activate
-   $ python3
-   >>> import numpy
-
-In general, there should not be much difference between ``spack env activate``
-and using the virtual environment. The main advantage of ``spack env activate``
-is that it knows about more packages than just Python packages, and it may set
-additional runtime variables that are not covered by the virtual environment
-activation script.
-
-See :ref:`environments` for a more in-depth description of Spack
-environments and customizations to views.
+We'll learn more about Spack's spec syntax in the next section.
 
 
 .. _sec-specs:
@@ -1175,17 +1096,6 @@ unspecified version, but packages can depend on other packages with
 could depend on ``mpich@1.2:`` if it can only build with version
 ``1.2`` or higher of ``mpich``.
 
-.. note:: Windows Spec Syntax Caveats
-   Windows has a few idiosyncrasies when it comes to the Spack spec syntax and the use of certain shells
-   Spack's spec dependency syntax uses the carat (``^``) character, however this is an escape string in CMD
-   so it must be escaped with an additional carat (i.e. ``^^``).
-   CMD also will attempt to interpret strings with ``=`` characters in them. Any spec including this symbol
-   must double quote the string.
-
-   Note: All of these issues are unique to CMD, they can be avoided by using Powershell.
-
-   For more context on these caveats see the related issues: `carat <https://github.com/spack/spack/issues/42833>`_ and `equals <https://github.com/spack/spack/issues/43348>`_
-
 Below are more details about the specifiers that you can add to specs.
 
 .. _version-specifier:
@@ -1209,9 +1119,6 @@ and ``3.4.2``.  Similarly, ``@4.2:`` means any version above and including
 ``4.2``.  As a short-hand, ``@3`` is equivalent to the range ``@3:3`` and
 includes any version with major version ``3``.
 
-Versions are ordered lexicograpically by its components. For more details
-on the order, see :ref:`the packaging guide <version-comparison>`.
-
 Notice that you can distinguish between the specific version ``@=3.2`` and
 the range ``@3.2``. This is useful for packages that follow a versioning
 scheme that omits the zero patch version number: ``3.2``, ``3.2.1``,
@@ -1223,10 +1130,6 @@ A version specifier can also be a list of ranges and specific versions,
 separated by commas.  For example, ``@1.0:1.5,=1.7.1`` matches any version
 in the range ``1.0:1.5`` and the specific version ``1.7.1``.
 
-^^^^^^^^^^^^
-Git versions
-^^^^^^^^^^^^
-
 For packages with a ``git`` attribute, ``git`` references
 may be specified instead of a numerical version i.e. branches, tags
 and commits. Spack will stage and build based off the ``git``
@@ -1359,10 +1262,6 @@ For example, for the ``stackstart`` variant:
     mpileaks stackstart==4   # variant will be propagated to dependencies
     mpileaks stackstart=4    # only mpileaks will have this variant value
 
-Spack also allows variants to be propagated from a package that does
-not have that variant.
-
-
 ^^^^^^^^^^^^^^
 Compiler Flags
 ^^^^^^^^^^^^^^
@@ -1448,12 +1347,22 @@ the reserved keywords ``platform``, ``os`` and ``target``:
    $ spack install libelf os=ubuntu18.04
    $ spack install libelf target=broadwell
 
+or together by using the reserved keyword ``arch``:
+
+.. code-block:: console
+
+   $ spack install libelf arch=cray-CNL10-haswell
+
 Normally users don't have to bother specifying the architecture if they
 are installing software for their current host, as in that case the
 values will be detected automatically.  If you need fine-grained control
 over which packages use which targets (or over *all* packages' default
 target), see :ref:`package-preferences`.
 
+.. admonition:: Cray machines
+
+  The situation is a little bit different for Cray machines and a detailed
+  explanation on how the architecture can be set on them can be found at :ref:`cray-support`
 
 .. _support-for-microarchitectures:
 
@@ -1789,6 +1698,165 @@ check only local packages (as opposed to those used transparently from
 ``upstream`` spack instances) and the ``-j,--json`` option to output
 machine-readable json data for any errors.
 
+
+.. _extensions:
+
+---------------------------
+Extensions & Python support
+---------------------------
+
+Spack's installation model assumes that each package will live in its
+own install prefix.  However, certain packages are typically installed
+*within* the directory hierarchy of other packages.  For example,
+`Python <https://www.python.org>`_ packages are typically installed in the
+``$prefix/lib/python-2.7/site-packages`` directory.
+
+In Spack, installation prefixes are immutable, so this type of installation
+is not directly supported. However, it is possible to create views that
+allow you to merge install prefixes of multiple packages into a single new prefix.
+Views are a convenient way to get a more traditional filesystem structure.
+Using *extensions*, you can ensure that Python packages always share the
+same prefix in the view as Python itself. Suppose you have
+Python installed like so:
+
+.. code-block:: console
+
+   $ spack find python
+   ==> 1 installed packages.
+   -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
+   python@2.7.8
+
+.. _cmd-spack-extensions:
+
+^^^^^^^^^^^^^^^^^^^^
+``spack extensions``
+^^^^^^^^^^^^^^^^^^^^
+
+You can find extensions for your Python installation like this:
+
+.. code-block:: console
+
+   $ spack extensions python
+   ==> python@2.7.8%gcc@4.4.7 arch=linux-debian7-x86_64-703c7a96
+   ==> 36 extensions:
+   geos          py-ipython     py-pexpect    py-pyside            py-sip
+   py-basemap    py-libxml2     py-pil        py-pytz              py-six
+   py-biopython  py-mako        py-pmw        py-rpy2              py-sympy
+   py-cython     py-matplotlib  py-pychecker  py-scientificpython  py-virtualenv
+   py-dateutil   py-mpi4py      py-pygments   py-scikit-learn
+   py-epydoc     py-mx          py-pylint     py-scipy
+   py-gnuplot    py-nose        py-pyparsing  py-setuptools
+   py-h5py       py-numpy       py-pyqt       py-shiboken
+
+   ==> 12 installed:
+   -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
+   py-dateutil@2.4.0    py-nose@1.3.4       py-pyside@1.2.2
+   py-dateutil@2.4.0    py-numpy@1.9.1      py-pytz@2014.10
+   py-ipython@2.3.1     py-pygments@2.0.1   py-setuptools@11.3.1
+   py-matplotlib@1.4.2  py-pyparsing@2.0.3  py-six@1.9.0
+
+The extensions are a subset of what's returned by ``spack list``, and
+they are packages like any other.  They are installed into their own
+prefixes, and you can see this with ``spack find --paths``:
+
+.. code-block:: console
+
+   $ spack find --paths py-numpy
+   ==> 1 installed packages.
+   -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
+       py-numpy@1.9.1  ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/py-numpy@1.9.1-66733244
+
+However, even though this package is installed, you cannot use it
+directly when you run ``python``:
+
+.. code-block:: console
+
+   $ spack load python
+   $ python
+   Python 2.7.8 (default, Feb 17 2015, 01:35:25)
+   [GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux2
+   Type "help", "copyright", "credits" or "license" for more information.
+   >>> import numpy
+   Traceback (most recent call last):
+     File "<stdin>", line 1, in <module>
+   ImportError: No module named numpy
+   >>>
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Using Extensions in Environments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The recommended way of working with extensions such as ``py-numpy``
+above is through :ref:`Environments <environments>`. For example,
+the following creates an environment in the current working directory
+with a filesystem view in the ``./view`` directory:
+
+.. code-block:: console
+
+   $ spack env create --with-view view --dir .
+   $ spack -e . add py-numpy
+   $ spack -e . concretize
+   $ spack -e . install
+
+We recommend environments for two reasons. Firstly, environments
+can be activated (requires :ref:`shell-support`):
+
+.. code-block:: console
+
+   $ spack env activate .
+
+which sets all the right environment variables such as ``PATH`` and
+``PYTHONPATH``. This ensures that
+
+.. code-block:: console
+
+   $ python
+   >>> import numpy
+
+works. Secondly, even without shell support, the view ensures
+that Python can locate its extensions:
+
+.. code-block:: console
+
+   $ ./view/bin/python
+   >>> import numpy
+
+See :ref:`environments` for a more in-depth description of Spack
+environments and customizations to views.
+
+^^^^^^^^^^^^^^^^^^^^
+Using ``spack load``
+^^^^^^^^^^^^^^^^^^^^
+
+A more traditional way of using Spack and extensions is ``spack load``
+(requires :ref:`shell-support`). This will add the extension to ``PYTHONPATH``
+in your current shell, and Python itself will be available in the ``PATH``:
+
+.. code-block:: console
+
+   $ spack load py-numpy
+   $ python
+   >>> import numpy
+
+The loaded packages can be checked using ``spack find --loaded``
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Loading Extensions via Modules
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Apart from ``spack env activate`` and ``spack load``, you can load numpy
+through your environment modules (using ``environment-modules`` or
+``lmod``). This will also add the extension to the ``PYTHONPATH`` in
+your current shell.
+
+.. code-block:: console
+
+   $ module load <name of numpy module>
+
+If you do not know the name of the specific numpy module you wish to
+load, you can use the ``spack module tcl|lmod loads`` command to get
+the name of the module from the Spack spec.
+
 -----------------------
 Filesystem requirements
 -----------------------

lib/spack/docs/binary_caches.rst

@@ -220,40 +220,6 @@ section of the configuration:
 
 .. _binary_caches_oci:
 
----------------------------------
-Automatic push to a build cache
----------------------------------
-
-Sometimes it is convenient to push packages to a build cache as soon as they are installed. Spack can do this by setting autopush flag when adding a mirror:
-
-.. code-block:: console
-
-    $ spack mirror add --autopush <name> <url or path>
-
-Or the autopush flag can be set for an existing mirror:
-
-.. code-block:: console
-
-    $ spack mirror set --autopush <name>  # enable automatic push for an existing mirror
-    $ spack mirror set --no-autopush <name>  # disable automatic push for an existing mirror
-
-Then after installing a package it is automatically pushed to all mirrors with ``autopush: true``. The command
-
-.. code-block:: console
-
-    $ spack install <package>
-
-will have the same effect as
-
-.. code-block:: console
-
-    $ spack install <package>
-    $ spack buildcache push <cache> <package>  # for all caches with autopush: true
-
-.. note::
-
-    Packages are automatically pushed to a build cache only if they are built from source.
-
 -----------------------------------------
 OCI / Docker V2 registries as build cache
 -----------------------------------------

lib/spack/docs/bootstrapping.rst

@@ -87,7 +87,7 @@ You can check what is installed in the bootstrapping store at any time using:
 
 .. code-block:: console
 
-   % spack -b find
+   % spack find -b
    ==> Showing internal bootstrap store at "/Users/spack/.spack/bootstrap/store"
    ==> 11 installed packages
    -- darwin-catalina-x86_64 / apple-clang@12.0.0 ------------------
@@ -101,7 +101,7 @@ In case it is needed you can remove all the software in the current bootstrappin
    % spack clean -b
    ==> Removing bootstrapped software and configuration in "/Users/spack/.spack/bootstrap"
 
-   % spack -b find
+   % spack find -b
    ==> Showing internal bootstrap store at "/Users/spack/.spack/bootstrap/store"
    ==> 0 installed packages
 
@@ -175,4 +175,4 @@ bootstrapping.
 
 This command needs to be run on a machine with internet access and the resulting folder
 has to be moved over to the air-gapped system. Once the local sources are added using the
-commands suggested at the prompt, they can be used to bootstrap Spack.
+commands suggested at the prompt, they can be used to bootstrap Spack.

lib/spack/docs/build_settings.rst

@@ -21,86 +21,23 @@ is the following:
 Reuse already installed packages
 --------------------------------
 
-The ``reuse`` attribute controls how aggressively Spack reuses binary packages during concretization. The
-attribute can either be a single value, or an object for more complex configurations.
-
-In the former case ("single value") it allows Spack to:
-
-1. Reuse installed packages and buildcaches for all the specs to be concretized, when ``true``
-2. Reuse installed packages and buildcaches only for the dependencies of the root specs, when ``dependencies``
-3. Disregard reusing installed packages and buildcaches, when ``false``
-
-In case a finer control over which specs are reused is needed, then the value of this attribute can be
-an object, with the following keys:
-
-1. ``roots``: if ``true`` root specs are reused, if ``false`` only dependencies of root specs are reused
-2. ``from``: list of sources from which reused specs are taken
-
-Each source in ``from`` is itself an object:
-
-.. list-table:: Attributes for a source or reusable specs
-   :header-rows: 1
-
-   * - Attribute name
-     - Description
-   * - type (mandatory, string)
-     - Can be ``local``, ``buildcache``, or ``external``
-   * - include (optional, list of specs)
-     - If present, reusable specs must match at least one of the constraint in the list
-   * - exclude (optional, list of specs)
-     - If present, reusable specs must not match any of the constraint in the list.
-
-For instance, the following configuration:
-
-.. code-block:: yaml
-
-   concretizer:
-     reuse:
-       roots: true
-       from:
-       - type: local
-         include:
-         - "%gcc"
-         - "%clang"
-
-tells the concretizer to reuse all specs compiled with either ``gcc`` or ``clang``, that are installed
-in the local store. Any spec from remote buildcaches is disregarded.
-
-To reduce the boilerplate in configuration files, default values for the ``include`` and
-``exclude`` options can be pushed up one level:
-
-.. code-block:: yaml
-
-   concretizer:
-     reuse:
-       roots: true
-       include:
-       - "%gcc"
-       from:
-       - type: local
-       - type: buildcache
-       - type: local
-         include:
-         - "foo %oneapi"
-
-In the example above we reuse all specs compiled with ``gcc`` from the local store
-and remote buildcaches, and we also reuse ``foo %oneapi``. Note that the last source of
-specs override the default ``include`` attribute.
-
-For one-off concretizations, the are command line arguments for each of the simple "single value"
-configurations. This means a user can:
+The ``reuse`` attribute controls whether Spack will prefer to use installed packages (``true``), or
+whether it will do a "fresh" installation and prefer the latest settings from
+``package.py`` files and ``packages.yaml`` (``false``).
+You can use:
 
 .. code-block:: console
 
    % spack install --reuse <spec>
 
-to enable reuse for a single installation, or:
+to enable reuse for a single installation, and you can use:
 
 .. code-block:: console
 
    spack install --fresh <spec>
 
 to do a fresh install if ``reuse`` is enabled by default.
+``reuse: dependencies`` is the default.
 
 .. seealso::
 
@@ -166,106 +103,3 @@ while `py-numpy` still needs an older version:
 
 Up to Spack v0.20 ``duplicates:strategy:none`` was the default (and only) behavior. From Spack v0.21 the
 default behavior is ``duplicates:strategy:minimal``.
-
---------
-Splicing
---------
-
-The ``splice`` key covers config attributes for splicing specs in the solver.
-
-"Splicing" is a method for replacing a dependency with another spec
-that provides the same package or virtual. There are two types of
-splices, referring to different behaviors for shared dependencies
-between the root spec and the new spec replacing a dependency:
-"transitive" and "intransitive". A "transitive" splice is one that
-resolves all conflicts by taking the dependency from the new node. An
-"intransitive" splice is one that resolves all conflicts by taking the
-dependency from the original root. From a theory perspective, hybrid
-splices are possible but are not modeled by Spack.
-
-All spliced specs retain a ``build_spec`` attribute that points to the
-original Spec before any splice occurred. The ``build_spec`` for a
-non-spliced spec is itself.
-
-The figure below shows examples of transitive and intransitive splices:
-
-.. figure:: images/splices.png
-   :align: center
-
-The concretizer can be configured to explicitly splice particular
-replacements for a target spec. Splicing will allow the user to make
-use of generically built public binary caches, while swapping in
-highly optimized local builds for performance critical components
-and/or components that interact closely with the specific hardware
-details of the system. The most prominent candidate for splicing is
-MPI providers. MPI packages have relatively well-understood ABI
-characteristics, and most High Performance Computing facilities deploy
-highly optimized MPI packages tailored to their particular
-hardware. The following config block configures Spack to replace
-whatever MPI provider each spec was concretized to use with the
-particular package of ``mpich`` with the hash that begins ``abcdef``.
-
-.. code-block:: yaml
-
-   concretizer:
-     splice:
-       explicit:
-       - target: mpi
-         replacement: mpich/abcdef
-         transitive: false
-
-.. warning::
-
-   When configuring an explicit splice, you as the user take on the
-   responsibility for ensuring ABI compatibility between the specs
-   matched by the target and the replacement you provide. If they are
-   not compatible, Spack will not warn you and your application will
-   fail to run.
-
-The ``target`` field of an explicit splice can be any abstract
-spec. The ``replacement`` field must be a spec that includes the hash
-of a concrete spec, and the replacement must either be the same
-package as the target, provide the virtual that is the target, or
-provide a virtual that the target provides. The ``transitive`` field
-is optional -- by default, splices will be transitive.
-
-.. note::
-
-   With explicit splices configured, it is possible for Spack to
-   concretize to a spec that does not satisfy the input. For example,
-   with the config above ``hdf5 ^mvapich2`` will concretize to user
-   ``mpich/abcdef`` instead of ``mvapich2`` as the MPI provider. Spack
-   will warn the user in this case, but will not fail the
-   concretization.
-
-.. _automatic_splicing:
-
-^^^^^^^^^^^^^^^^^^
-Automatic Splicing
-^^^^^^^^^^^^^^^^^^
-
-The Spack solver can be configured to do automatic splicing for
-ABI-compatible packages. Automatic splices are enabled in the concretizer
-config section
-
-.. code-block:: yaml
-
-   concretizer:
-     splice:
-       automatic: True
-
-Packages can include ABI-compatibility information using the
-``can_splice`` directive. See :ref:`the packaging
-guide<abi_compatibility>` for instructions on specifying ABI
-compatibility using the ``can_splice`` directive.
-
-.. note::
-
-   The ``can_splice`` directive is experimental and may be changed in
-   future versions.
-
-When automatic splicing is enabled, the concretizer will combine any
-number of ABI-compatible specs if possible to reuse installed packages
-and packages available from binary caches. The end result of these
-specs is equivalent to a series of transitive/intransitive splices,
-but the series may be non-obvious.

lib/spack/docs/build_systems/autotoolspackage.rst

@@ -147,15 +147,6 @@ example, the ``bash`` shell is used to run the ``autogen.sh`` script.
    def autoreconf(self, spec, prefix):
        which("bash")("autogen.sh")
 
-If the ``package.py`` has build instructions in a separate
-:ref:`builder class <multiple_build_systems>`, the signature for a phase changes slightly:
-
-.. code-block:: python
-
-   class AutotoolsBuilder(AutotoolsBuilder):
-      def autoreconf(self, pkg, spec, prefix):
-         which("bash")("autogen.sh")
-
 """""""""""""""""""""""""""""""""""""""
 patching configure or Makefile.in files
 """""""""""""""""""""""""""""""""""""""

lib/spack/docs/build_systems/cmakepackage.rst

@@ -250,7 +250,7 @@ generator is Ninja. To switch to the Ninja generator, simply add:
 
 .. code-block:: python
 
-   generator("ninja")
+   generator = "Ninja"
 
 
 ``CMakePackage`` defaults to "Unix Makefiles". If you switch to the

lib/spack/docs/build_systems/custompackage.rst

@@ -130,19 +130,14 @@ before or after a particular phase. For example, in ``perl``, we see:
 
    @run_after("install")
    def install_cpanm(self):
-        spec = self.spec
-        maker = make
-        cpan_dir = join_path("cpanm", "cpanm")
-        if sys.platform == "win32":
-            maker = nmake
-            cpan_dir = join_path(self.stage.source_path, cpan_dir)
-            cpan_dir = windows_sfn(cpan_dir)
-        if "+cpanm" in spec:
-            with working_dir(cpan_dir):
-                perl = spec["perl"].command
-                perl("Makefile.PL")
-                maker()
-                maker("install")
+       spec = self.spec
+
+       if spec.satisfies("+cpanm"):
+           with working_dir(join_path("cpanm", "cpanm")):
+               perl = spec["perl"].command
+               perl("Makefile.PL")
+               make()
+               make("install")
 
 This extra step automatically installs ``cpanm`` in addition to the
 base Perl installation.
@@ -181,14 +176,8 @@ In the ``perl`` package, we can see:
 
    @run_after("build")
    @on_package_attributes(run_tests=True)
-   def build_test(self):
-        if sys.platform == "win32":
-            win32_dir = os.path.join(self.stage.source_path, "win32")
-            win32_dir = windows_sfn(win32_dir)
-            with working_dir(win32_dir):
-                nmake("test", ignore_quotes=True)
-        else:
-            make("test")
+   def test(self):
+       make("test")
 
 As you can guess, this runs ``make test`` *after* building the package,
 if and only if testing is requested. Again, this is not specific to

lib/spack/docs/build_systems/inteloneapipackage.rst

@@ -25,7 +25,7 @@ use Spack to build packages with the tools.
 The Spack Python class ``IntelOneapiPackage`` is a base class that is
 used by ``IntelOneapiCompilers``, ``IntelOneapiMkl``,
 ``IntelOneapiTbb`` and other classes to implement the oneAPI
-packages. Search for ``oneAPI`` at `packages.spack.io <https://packages.spack.io>`_ for the full
+packages. Search for ``oneAPI`` at `<packages.spack.io>`_ for the full
 list of available oneAPI packages, or use::
 
   spack list -d oneAPI

lib/spack/docs/build_systems/perlpackage.rst

@@ -173,72 +173,6 @@ arguments to ``Makefile.PL`` or ``Build.PL`` by overriding
        ]
 
 
-^^^^^^^
-Testing
-^^^^^^^
-
-``PerlPackage`` provides a simple stand-alone test of the successfully
-installed package to confirm that installed perl module(s) can be used.
-These tests can be performed any time after the installation using
-``spack -v test run``. (For more information on the command, see 
-:ref:`cmd-spack-test-run`.)
-
-The base class automatically detects perl modules based on the presence
-of ``*.pm`` files under the package's library directory. For example,
-the files under ``perl-bignum``'s perl library are:
-
-.. code-block:: console
-
-   $ find . -name "*.pm"
-   ./bigfloat.pm
-   ./bigrat.pm
-   ./Math/BigFloat/Trace.pm
-   ./Math/BigInt/Trace.pm
-   ./Math/BigRat/Trace.pm
-   ./bigint.pm
-   ./bignum.pm
-
-
-which results in the package having the ``use_modules`` property containing:
-
-.. code-block:: python
-
-   use_modules = [
-       "bigfloat",
-       "bigrat",
-       "Math::BigFloat::Trace",
-       "Math::BigInt::Trace",
-       "Math::BigRat::Trace",
-       "bigint",
-       "bignum",
-   ]
-
-.. note::
-
-   This list can often be used to catch missing dependencies.
-
-If the list is somehow wrong, you can provide the names of the modules
-yourself by overriding ``use_modules`` like so:
-
- .. code-block:: python
-
-    use_modules = ["bigfloat", "bigrat", "bigint", "bignum"]
-
-If you only want a subset of the automatically detected modules to be
-tested, you could instead define the ``skip_modules`` property on the
-package. So, instead of overriding ``use_modules`` as shown above, you
-could define the following:
-
- .. code-block:: python
-
-    skip_modules = [
-        "Math::BigFloat::Trace",
-        "Math::BigInt::Trace",
-        "Math::BigRat::Trace",
-    ]
-
-for the same use tests.
-
 ^^^^^^^^^^^^^^^^^^^^^
 Alternatives to Spack
 ^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/pythonpackage.rst

@@ -718,45 +718,23 @@ command-line tool, or C/C++/Fortran program with optional Python
 modules? The former should be prepended with ``py-``, while the
 latter should not.
 
-""""""""""""""""""""""""""""""
-``extends`` vs. ``depends_on``
-""""""""""""""""""""""""""""""
+""""""""""""""""""""""
+extends vs. depends_on
+""""""""""""""""""""""
 
+This is very similar to the naming dilemma above, with a slight twist.
 As mentioned in the :ref:`Packaging Guide <packaging_extensions>`,
 ``extends`` and ``depends_on`` are very similar, but ``extends`` ensures
 that the extension and extendee share the same prefix in views.
 This allows the user to import a Python module without
 having to add that module to ``PYTHONPATH``.
 
-Additionally, ``extends("python")`` adds a dependency on the package
-``python-venv``. This improves isolation from the system, whether
-it's during the build or at runtime: user and system site packages
-cannot accidentally be used by any package that ``extends("python")``.
-
-As a rule of thumb: if a package does not install any Python modules
-of its own, and merely puts a Python script in the ``bin`` directory,
-then there is no need for ``extends``. If the package installs modules
-in the ``site-packages`` directory, it requires ``extends``.
-
-"""""""""""""""""""""""""""""""""""""
-Executing ``python`` during the build
-"""""""""""""""""""""""""""""""""""""
-
-Whenever you need to execute a Python command or pass the path of the
-Python interpreter to the build system, it is best to use the global
-variable ``python`` directly. For example:
-
-.. code-block:: python
-
-    @run_before("install")
-    def recythonize(self):
-        python("setup.py", "clean")  # use the `python` global
-
-As mentioned in the previous section, ``extends("python")`` adds an
-automatic dependency on ``python-venv``, which is a virtual environment
-that guarantees build isolation. The ``python`` global always refers to
-the correct Python interpreter, whether the package uses ``extends("python")``
-or ``depends_on("python")``.
+When deciding between ``extends`` and ``depends_on``, the best rule of
+thumb is to check the installation prefix. If Python libraries are
+installed to ``<prefix>/lib/pythonX.Y/site-packages``, then you
+should use ``extends``. If Python libraries are installed elsewhere
+or the only files that get installed reside in ``<prefix>/bin``, then
+don't use ``extends``.
 
 ^^^^^^^^^^^^^^^^^^^^^
 Alternatives to Spack

lib/spack/docs/build_systems/sconspackage.rst

@@ -49,14 +49,14 @@ following phases:
 #. ``install`` - install the package
 
 Package developers often add unit tests that can be invoked with
-``scons test`` or ``scons check``. Spack provides a ``build_test`` method
+``scons test`` or ``scons check``. Spack provides a ``test`` method
 to handle this. Since we don't know which one the package developer
-chose, the ``build_test`` method does nothing by default, but can be easily
+chose, the ``test`` method does nothing by default, but can be easily
 overridden like so:
 
 .. code-block:: python
 
-   def build_test(self):
+   def test(self):
        scons("check")
 
 

lib/spack/docs/chain.rst

@@ -5,14 +5,13 @@
 
 .. chain:
 
-=============================================
-Chaining Spack Installations (upstreams.yaml)
-=============================================
+============================
+Chaining Spack Installations
+============================
 
 You can point your Spack installation to another installation to use any
 packages that are installed there. To register the other Spack instance,
-you can add it as an entry to ``upstreams.yaml`` at any of the
-:ref:`configuration-scopes`:
+you can add it as an entry to ``upstreams.yaml``:
 
 .. code-block:: yaml
 
@@ -23,8 +22,7 @@ you can add it as an entry to ``upstreams.yaml`` at any of the
       install_tree: /path/to/another/spack/opt/spack
 
 ``install_tree`` must point to the ``opt/spack`` directory inside of the
-Spack base directory, or the location of the ``install_tree`` defined
-in :ref:`config.yaml <config-yaml>`.
+Spack base directory.
 
 Once the upstream Spack instance has been added, ``spack find`` will
 automatically check the upstream instance when querying installed packages,

lib/spack/docs/conf.py

@@ -199,31 +199,22 @@ def setup(sphinx):
     ("py:class", "contextlib.contextmanager"),
     ("py:class", "module"),
     ("py:class", "_io.BufferedReader"),
-    ("py:class", "_io.BytesIO"),
     ("py:class", "unittest.case.TestCase"),
     ("py:class", "_frozen_importlib_external.SourceFileLoader"),
     ("py:class", "clingo.Control"),
     ("py:class", "six.moves.urllib.parse.ParseResult"),
     ("py:class", "TextIO"),
     ("py:class", "hashlib._Hash"),
-    ("py:class", "concurrent.futures._base.Executor"),
     # Spack classes that are private and we don't want to expose
     ("py:class", "spack.provider_index._IndexBase"),
     ("py:class", "spack.repo._PrependFileLoader"),
-    ("py:class", "spack.build_systems._checks.BuilderWithDefaults"),
+    ("py:class", "spack.build_systems._checks.BaseBuilder"),
     # Spack classes that intersphinx is unable to resolve
     ("py:class", "spack.version.StandardVersion"),
     ("py:class", "spack.spec.DependencySpec"),
-    ("py:class", "spack.spec.ArchSpec"),
     ("py:class", "spack.spec.InstallStatus"),
     ("py:class", "spack.spec.SpecfileReaderBase"),
     ("py:class", "spack.install_test.Pb"),
-    ("py:class", "spack.filesystem_view.SimpleFilesystemView"),
-    ("py:class", "spack.traverse.EdgeAndDepth"),
-    ("py:class", "archspec.cpu.microarchitecture.Microarchitecture"),
-    ("py:class", "spack.compiler.CompilerCache"),
-    # TypeVar that is not handled correctly
-    ("py:class", "llnl.util.lang.T"),
 ]
 
 # The reST default role (used for this markup: `text`) to use for all documents.

lib/spack/docs/config_yaml.rst

@@ -145,25 +145,6 @@ hosts when making ``ssl`` connections.  Set to ``false`` to disable, and
 tools like ``curl`` will use their ``--insecure`` options.  Disabling
 this can expose you to attacks.  Use at your own risk.
 
---------------------
-``ssl_certs``
---------------------
-
-Path to custom certificats for SSL verification. The value can be a 
-filesytem path, or an environment variable that expands to an absolute file path.
-The default value is set to the environment variable ``SSL_CERT_FILE``
-to use the same syntax used by many other applications that automatically
-detect custom certificates.
-When ``url_fetch_method:curl`` the ``config:ssl_certs`` should resolve to
-a single file.  Spack will then set the environment variable ``CURL_CA_BUNDLE``
-in the subprocess calling ``curl``.
-If ``url_fetch_method:urllib`` then files and directories are supported i.e. 
-``config:ssl_certs:$SSL_CERT_FILE`` or ``config:ssl_certs:$SSL_CERT_DIR``
-will work.
-In all cases the expanded path must be absolute for Spack to use the certificates.
-Certificates relative to an environment can be created by prepending the path variable
-with the Spack configuration variable``$env``.
-
 --------------------
 ``checksum``
 --------------------

lib/spack/docs/configuration.rst

@@ -73,12 +73,9 @@ are six configuration scopes. From lowest to highest:
    Spack instance per project) or for site-wide settings on a multi-user
    machine (e.g., for a common Spack instance).
 
-#. **plugin**: Read from a Python project's entry points. Settings here affect
-   all instances of Spack running with the same Python installation.  This scope takes higher precedence than site, system, and default scopes.
-
 #. **user**: Stored in the home directory: ``~/.spack/``. These settings
    affect all instances of Spack and take higher precedence than site,
-   system, plugin, or defaults scopes.
+   system, or defaults scopes.
 
 #. **custom**: Stored in a custom directory specified by ``--config-scope``.
    If multiple scopes are listed on the command line, they are ordered
@@ -199,45 +196,6 @@ with MPICH. You can create different configuration scopes for use with
                mpi: [mpich]
 
 
-.. _plugin-scopes:
-
-^^^^^^^^^^^^^
-Plugin scopes
-^^^^^^^^^^^^^
-
-.. note::
-   Python version >= 3.8 is required to enable plugin configuration.
-
-Spack can be made aware of configuration scopes that are installed as part of a python package.  To do so, register a function that returns the scope's path to the ``"spack.config"`` entry point.  Consider the Python package ``my_package`` that includes Spack configurations:
-
-.. code-block:: console
-
-  my-package/
-  ├── src
-  │   ├── my_package
-  │   │   ├── __init__.py
-  │   │   └── spack/
-  │   │   │   └── config.yaml
-  └── pyproject.toml
-
-adding the following to ``my_package``'s ``pyproject.toml`` will make ``my_package``'s ``spack/`` configurations visible to Spack when ``my_package`` is installed:
-
-.. code-block:: toml
-
-   [project.entry_points."spack.config"]
-   my_package = "my_package:get_config_path"
-
-The function ``my_package.get_extension_path`` in ``my_package/__init__.py`` might look like
-
-.. code-block:: python
-
-   import importlib.resources
-
-   def get_config_path():
-       dirname = importlib.resources.files("my_package").joinpath("spack")
-       if dirname.exists():
-           return str(dirname)
-
 .. _platform-scopes:
 
 ------------------------
@@ -281,7 +239,7 @@ When spack queries for configuration parameters, it searches in
 higher-precedence scopes first. So, settings in a higher-precedence file
 can override those with the same key in a lower-precedence one. For
 list-valued settings, Spack *prepends* higher-precedence settings to
-lower-precedence settings. Completely ignoring lower-precedence configuration
+lower-precedence settings. Completely ignoring higher-level configuration
 options is supported with the ``::`` notation for keys (see
 :ref:`config-overrides` below).
 
@@ -511,7 +469,6 @@ Spack understands over a dozen special variables. These are:
 * ``$target_family``. The target family for the current host, as
   detected by ArchSpec. E.g. ``x86_64`` or ``aarch64``.
 * ``$date``: the current date in the format YYYY-MM-DD
-* ``$spack_short_version``: the Spack version truncated to the first components.
 
 
 Note that, as with shell variables, you can write these as ``$varname``

lib/spack/docs/containers.rst

@@ -194,18 +194,21 @@ The OS that are currently supported are summarized in the table below:
    * - Operating System
      - Base Image
      - Spack Image
+   * - Ubuntu 18.04
+     - ``ubuntu:18.04``
+     - ``spack/ubuntu-bionic``
    * - Ubuntu 20.04
      - ``ubuntu:20.04``
      - ``spack/ubuntu-focal``
    * - Ubuntu 22.04
      - ``ubuntu:22.04``
      - ``spack/ubuntu-jammy``
-   * - Ubuntu 24.04
-     - ``ubuntu:24.04``
-     - ``spack/ubuntu-noble``
-   * - CentOS Stream9
-     - ``quay.io/centos/centos:stream9``
-     - ``spack/centos-stream9``
+   * - CentOS 7
+     - ``centos:7``
+     - ``spack/centos7``
+   * - CentOS Stream
+     - ``quay.io/centos/centos:stream``
+     - ``spack/centos-stream``
    * - openSUSE Leap
      - ``opensuse/leap``
      - ``spack/leap15``
@@ -224,12 +227,12 @@ The OS that are currently supported are summarized in the table below:
    * - Rocky Linux 9
      - ``rockylinux:9``
      - ``spack/rockylinux9``
-   * - Fedora Linux 39
-     - ``fedora:39``
-     - ``spack/fedora39``
-   * - Fedora Linux 40
-     - ``fedora:40``
-     - ``spack/fedora40``
+   * - Fedora Linux 37
+     - ``fedora:37``
+     - ``spack/fedora37``
+   * - Fedora Linux 38
+     - ``fedora:38``
+     - ``spack/fedora38``
 
 
 

lib/spack/docs/contribution_guide.rst

@@ -184,7 +184,7 @@ Style Tests
 
 Spack uses `Flake8 <http://flake8.pycqa.org/en/latest/>`_ to test for
 `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_ conformance and
-`mypy <https://mypy.readthedocs.io/en/stable/>`_ for type checking. PEP 8 is
+`mypy <https://mypy.readthedocs.io/en/stable/>` for type checking. PEP 8 is
 a series of style guides for Python that provide suggestions for everything
 from variable naming to indentation. In order to limit the number of PRs that
 were mostly style changes, we decided to enforce PEP 8 conformance. Your PR
@@ -316,215 +316,6 @@ documentation tests to make sure there are no errors. Documentation changes can
 in some obfuscated warning messages. If you don't understand what they mean, feel free
 to ask when you submit your PR.
 
-.. _spack-builders-and-pipelines:
-
-^^^^^^^^^
-GitLab CI
-^^^^^^^^^
-
-""""""""""""""""""
-Build Cache Stacks
-""""""""""""""""""
-
-Spack welcomes the contribution of software stacks of interest to the community. These
-stacks are used to test package recipes and generate publicly available build caches.
-Spack uses GitLab CI for managing the orchestration of build jobs.
-
-GitLab Entry Point
-~~~~~~~~~~~~~~~~~~
-
-Add stack entrypoint to the ``share/spack/gitlab/cloud_pipelines/.gitlab-ci.yml``. There
-are two stages required for each new stack, the generation stage and the build stage.
-
-The generate stage is defined using the job template ``.generate`` configured with
-environment variables defining the name of the stack in ``SPACK_CI_STACK_NAME`` and the
-platform (``SPACK_TARGET_PLATFORM``) and architecture (``SPACK_TARGET_ARCH``) configuration,
-and the tags associated with the class of runners to build on.
-
-.. note::
-
-    The ``SPACK_CI_STACK_NAME`` must match the name of the directory containing the
-    stacks ``spack.yaml``.
-
-
-.. note::
-
-    The platform and architecture variables are specified in order to select the
-    correct configurations from the generic configurations used in Spack CI. The
-    configurations currently available are:
-
-    * ``.cray_rhel_zen4``
-    * ``.cray_sles_zen4``
-    * ``.darwin_aarch64``
-    * ``.darwin_x86_64``
-    * ``.linux_aarch64``
-    * ``.linux_icelake``
-    * ``.linux_neoverse_n1``
-    * ``.linux_neoverse_v1``
-    * ``.linux_neoverse_v2``
-    * ``.linux_power``
-    * ``.linux_skylake``
-    * ``.linux_x86_64``
-    * ``.linux_x86_64_v4``
-
-    New configurations can be added to accommodate new platforms and architectures.
-
-
-The build stage is defined as a trigger job that consumes the GitLab CI pipeline generated in
-the generate stage for this stack. Build stage jobs use the ``.build`` job template which
-handles the basic configuration.
-
-An example entry point for a new stack called ``my-super-cool-stack``
-
-.. code-block:: yaml
-
-    .my-super-cool-stack:
-      extends: [ ".linux_x86_64_v3" ]
-      variables:
-        SPACK_CI_STACK_NAME: my-super-cool-stack
-        tags: [ "all", "tags", "your", "job", "needs"]
-
-    my-super-cool-stack-generate:
-      extends: [ ".generate", ".my-super-cool-stack" ]
-      image: my-super-cool-stack-image:0.0.1
-
-    my-super-cool-stack-build:
-      extends: [ ".build", ".my-super-cool-stack" ]
-      trigger:
-        include:
-          - artifact: jobs_scratch_dir/cloud-ci-pipeline.yml
-            job: my-super-cool-stack-generate
-        strategy: depend
-      needs:
-        - artifacts: True
-          job: my-super-cool-stack-generate
-
-
-Stack Configuration
-~~~~~~~~~~~~~~~~~~~
-
-The stack configuration is a spack environment file with two additional sections added.
-Stack configurations should be located in ``share/spack/gitlab/cloud_pipelines/stacks/<stack_name>/spack.yaml``.
-
-The ``ci`` section is generally used to define stack specific mappings such as image or tags.
-For more information on what can go into the ``ci`` section refer to the docs on pipelines.
-
-The ``cdash`` section is used for defining where to upload the results of builds. Spack configures
-most of the details for posting pipeline results to
-`cdash.spack.io <https://cdash.spack.io/index.php?project=Spack+Testing>`_. The only
-requirement in the stack configuration is to define a ``build-group`` that is unique,
-this is usually the long name of the stack.
-
-An example stack that builds ``zlib``.
-
-.. code-block:: yaml
-
-    spack:
-      view: false
-      packages:
-        all:
-          require: ["%gcc", "target=x86_64_v3"]
-      specs:
-      - zlib
-
-      ci:
-        pipeline-gen
-        - build-job:
-            image: my-super-cool-stack-image:0.0.1
-
-      cdash:
-        build-group: My Super Cool Stack
-
-.. note::
-
-    The ``image`` used in the ``*-generate`` job must match exactly the ``image`` used in the ``build-job``.
-    When the images do not match the build job may fail.
-
-
-"""""""""""""""""""
-Registering Runners
-"""""""""""""""""""
-
-Contributing computational resources to Spack's CI build farm is one way to help expand the
-capabilities and offerings of the public Spack build caches. Currently, Spack utilizes linux runners
-from AWS, Google, and the University of Oregon (UO).
-
-Runners require three key peices:
-* Runner Registration Token
-* Accurate tags
-* OIDC Authentication script
-* GPG keys
-
-
-Minimum GitLab Runner Version: ``16.1.0``
-`Intallation instructions <https://docs.gitlab.com/runner/install/>`_
-
-Registration Token
-~~~~~~~~~~~~~~~~~~
-
-The first step to contribute new runners is to open an issue in the `spack infrastructure <https://github.com/spack/spack-infrastructure/issues/new?assignees=&labels=runner-registration&projects=&template=runner_registration.yml>`_
-project. This will be reported to the spack infrastructure team who will guide users through the process
-of registering new runners for Spack CI.
-
-The information needed to register a runner is the motivation for the new resources, a semi-detailed description of
-the runner, and finallly the point of contact for maintaining the software on the runner.
-
-The point of contact will then work with the infrastruture team to obtain runner registration token(s) for interacting with
-with Spack's GitLab instance. Once the runner is active, this point of contact will also be responsible for updating the
-GitLab runner software to keep pace with Spack's Gitlab.
-
-Tagging
-~~~~~~~
-
-In the initial stages of runner registration it is important to **exclude** the special tag ``spack``. This will prevent
-the new runner(s) from being picked up for production CI jobs while it is configured and evaluated. Once it is determined
-that the runner is ready for production use the ``spack`` tag will be added.
-
-Because gitlab has no concept of tag exclustion, runners that provide specialized resource also require specialized tags.
-For example, a basic CPU only x86_64 runner may have a tag ``x86_64`` associated with it. However, a runner containing an
-CUDA capable GPU may have the tag ``x86_64-cuda`` to denote that it should only be used for packages that will benefit from
-a CUDA capable resource.
-
-OIDC
-~~~~
-
-Spack runners use OIDC authentication for connecting to the appropriate AWS bucket
-which is used for coordinating the communication of binaries between build jobs. In
-order to configure OIDC authentication, Spack CI runners use a python script with minimal
-dependencies. This script can be configured for runners as seen here using the ``pre_build_script``.
-
-.. code-block:: toml
-
-    [[runners]]
-      pre_build_script = """
-      echo 'Executing Spack pre-build setup script'
-
-      for cmd in "${PY3:-}" python3 python; do
-        if command -v > /dev/null "$cmd"; then
-          export PY3="$(command -v "$cmd")"
-          break
-        fi
-      done
-
-      if [ -z "${PY3:-}" ]; then
-        echo "Unable to find python3 executable"
-        exit 1
-      fi
-
-      $PY3 -c "import urllib.request;urllib.request.urlretrieve('https://raw.githubusercontent.com/spack/spack-infrastructure/main/scripts/gitlab_runner_pre_build/pre_build.py', 'pre_build.py')"
-      $PY3 pre_build.py > envvars
-
-      . ./envvars
-      rm -f envvars
-      unset GITLAB_OIDC_TOKEN
-      """
-
-GPG Keys
-~~~~~~~~
-
-Runners that may be utilized for ``protected`` CI require the registration of an intermediate signing key that
-can be used to sign packages. For more information on package signing read :ref:`key_architecture`.
-
 --------
 Coverage
 --------

lib/spack/docs/developer_guide.rst

@@ -181,6 +181,10 @@ Spec-related modules
 :mod:`spack.parser`
   Contains :class:`~spack.parser.SpecParser` and functions related to parsing specs.
 
+:mod:`spack.concretize`
+  Contains :class:`~spack.concretize.Concretizer` implementation,
+  which allows site administrators to change Spack's :ref:`concretization-policies`.
+
 :mod:`spack.version`
   Implements a simple :class:`~spack.version.Version` class with simple
   comparison semantics.  Also implements :class:`~spack.version.VersionRange`
@@ -333,9 +337,13 @@ inserting them at different places in the spack code base. Whenever a hook
 type triggers by way of a function call, we find all the hooks of that type,
 and run them.
 
-Spack defines hooks by way of a module in the ``lib/spack/spack/hooks`` directory.
-This module has to be registered in ``__init__.py`` so that Spack is aware of it.
-This section will cover the basic kind of hooks, and how to write them.
+Spack defines hooks by way of a module at ``lib/spack/spack/hooks`` where we can define
+types of hooks in the ``__init__.py``, and then python files in that folder
+can use hook functions. The files are automatically parsed, so if you write
+a new file for some integration (e.g., ``lib/spack/spack/hooks/myintegration.py``
+you can then write hook functions in that file that will be automatically detected,
+and run whenever your hook is called. This section will cover the basic kind
+of hooks, and how to write them.
 
 ^^^^^^^^^^^^^^
 Types of Hooks
@@ -349,23 +357,91 @@ If there is a hook that you would like and is missing, you can propose to add a
 ``pre_install(spec)``
 """""""""""""""""""""
 
-A ``pre_install`` hook is run within the install subprocess, directly before the install starts.
-It expects a single argument of a spec.
+A ``pre_install`` hook is run within an install subprocess, directly before
+the install starts. It expects a single argument of a spec, and is run in
+a multiprocessing subprocess. Note that if you see ``pre_install`` functions associated with packages these are not hooks
+as we have defined them here, but rather callback functions associated with
+a package install.
 
 
-"""""""""""""""""""""""""""""""""""""
-``post_install(spec, explicit=None)``
-"""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""
+``post_install(spec)``
+""""""""""""""""""""""
 
-A ``post_install`` hook is run within the install subprocess, directly after the install finishes,
-but before the build stage is removed and the spec is registered in the database. It expects two
-arguments: spec and an optional boolean indicating whether this spec is being installed explicitly.
+A ``post_install`` hook is run within an install subprocess, directly after
+the install finishes, but before the build stage is removed. If you
+write one of these hooks, you should expect it to accept a spec as the only
+argument. This is run in a multiprocessing subprocess. This ``post_install`` is
+also seen in packages, but in this context not related to the hooks described
+here.
 
-""""""""""""""""""""""""""""""""""""""""""""""""""""
-``pre_uninstall(spec)`` and ``post_uninstall(spec)``
-""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-These hooks are currently used for cleaning up module files after uninstall.
+""""""""""""""""""""""""""
+``on_install_start(spec)``
+""""""""""""""""""""""""""
+
+This hook is run at the beginning of ``lib/spack/spack/installer.py``,
+in the install function of a ``PackageInstaller``,
+and importantly is not part of a build process, but before it. This is when
+we have just newly grabbed the task, and are preparing to install. If you
+write a hook of this type, you should provide the spec to it.
+
+.. code-block:: python
+
+    def on_install_start(spec):
+        """On start of an install, we want to...
+        """
+        print('on_install_start')
+
+
+""""""""""""""""""""""""""""
+``on_install_success(spec)``
+""""""""""""""""""""""""""""
+
+This hook is run on a successful install, and is also run inside the build
+process, akin to ``post_install``. The main difference is that this hook
+is run outside of the context of the stage directory, meaning after the
+build stage has been removed and the user is alerted that the install was
+successful. If you need to write a hook that is run on success of a particular
+phase, you should use ``on_phase_success``.
+
+""""""""""""""""""""""""""""
+``on_install_failure(spec)``
+""""""""""""""""""""""""""""
+
+This hook is run given an install failure that happens outside of the build
+subprocess, but somewhere in ``installer.py`` when something else goes wrong.
+If you need to write a hook that is relevant to a failure within a build
+process, you would want to instead use ``on_phase_failure``.
+
+
+"""""""""""""""""""""""""""
+``on_install_cancel(spec)``
+"""""""""""""""""""""""""""
+
+The same, but triggered if a spec install is cancelled for any reason.
+
+
+"""""""""""""""""""""""""""""""""""""""""""""""
+``on_phase_success(pkg, phase_name, log_file)``
+"""""""""""""""""""""""""""""""""""""""""""""""
+
+This hook is run within the install subprocess, and specifically when a phase
+successfully finishes. Since we are interested in the package, the name of
+the phase, and any output from it, we require:
+
+ - **pkg**: the package variable, which also has the attached spec at ``pkg.spec``
+ - **phase_name**: the name of the phase that was successful (e.g., configure)
+ - **log_file**: the path to the file with output, in case you need to inspect or otherwise interact with it.
+
+"""""""""""""""""""""""""""""""""""""""""""""
+``on_phase_error(pkg, phase_name, log_file)``
+"""""""""""""""""""""""""""""""""""""""""""""
+
+In the case of an error during a phase, we might want to trigger some event
+with a hook, and this is the purpose of this particular hook. Akin to
+``on_phase_success`` we require the same variables - the package that failed,
+the name of the phase, and the log file where we might find errors.
 
 
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -544,11 +620,11 @@ With either interpreter you can run a single command:
 
 .. code-block:: console
 
-   $ spack python -c 'from spack.spec import Spec; Spec("python").concretized()'
-   ...
+   $ spack python -c 'import distro; distro.linux_distribution()'
+   ('Ubuntu', '18.04', 'Bionic Beaver')
 
-   $ spack python -i ipython -c 'from spack.spec import Spec; Spec("python").concretized()'
-   Out[1]: ...
+   $ spack python -i ipython -c 'import distro; distro.linux_distribution()'
+   Out[1]: ('Ubuntu', '18.04', 'Bionic Beaver')
 
 or a file:
 
@@ -708,27 +784,27 @@ Release branches
 ^^^^^^^^^^^^^^^^
 
 There are currently two types of Spack releases: :ref:`major releases
-<major-releases>` (``0.21.0``, ``0.22.0``, etc.) and :ref:`patch releases
-<patch-releases>` (``0.22.1``, ``0.22.2``, ``0.22.3``, etc.). Here is a
+<major-releases>` (``0.17.0``, ``0.18.0``, etc.) and :ref:`point releases
+<point-releases>` (``0.17.1``, ``0.17.2``, ``0.17.3``, etc.). Here is a
 diagram of how Spack release branches work::
 
-    o    branch: develop  (latest version, v0.23.0.dev0)
+    o    branch: develop  (latest version, v0.19.0.dev0)
     |
     o
-    | o  branch: releases/v0.22, tag: v0.22.1
+    | o  branch: releases/v0.18, tag: v0.18.1
     o |
-    | o  tag: v0.22.0
+    | o  tag: v0.18.0
     o |
     | o
     |/
     o
     |
     o
-    | o  branch: releases/v0.21, tag: v0.21.2
+    | o  branch: releases/v0.17, tag: v0.17.2
     o |
-    | o  tag: v0.21.1
+    | o  tag: v0.17.1
     o |
-    | o  tag: v0.21.0
+    | o  tag: v0.17.0
     o |
     | o
     |/
@@ -739,8 +815,8 @@ requests target ``develop``. The ``develop`` branch will report that its
 version is that of the next **major** release with a ``.dev0`` suffix.
 
 Each Spack release series also has a corresponding branch, e.g.
-``releases/v0.22`` has ``v0.22.x`` versions of Spack, and
-``releases/v0.21`` has ``v0.21.x`` versions. A major release is the first
+``releases/v0.18`` has ``0.18.x`` versions of Spack, and
+``releases/v0.17`` has ``0.17.x`` versions. A major release is the first
 tagged version on a release branch. Minor releases are back-ported from
 develop onto release branches. This is typically done by cherry-picking
 bugfix commits off of ``develop``.
@@ -770,40 +846,27 @@ for more details.
 Scheduling work for releases
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-We schedule work for **major releases** through `milestones
-<https://github.com/spack/spack/milestones>`_ and `GitHub Projects
-<https://github.com/spack/spack/projects>`_, while **patch releases** use `labels
-<https://github.com/spack/spack/labels>`_.
+We schedule work for releases by creating `GitHub projects
+<https://github.com/spack/spack/projects>`_. At any time, there may be
+several open release projects. For example, below are two releases (from
+some past version of the page linked above):
 
-There is only one milestone open at a time. Its name corresponds to the next major version, for
-example ``v0.23``. Important issues and pull requests should be assigned to this milestone by
-core developers, so that they are not forgotten at the time of release. The milestone is closed
-when the release is made, and a new milestone is created for the next major release.
+.. image:: images/projects.png
 
-Bug reports in GitHub issues are automatically labelled ``bug`` and ``triage``. Spack developers
-assign one of the labels ``impact-low``, ``impact-medium`` or ``impact-high``. This will make the
-issue appear in the `Triaged bugs <https://github.com/orgs/spack/projects/6>`_ project board.
-Important issues should be assigned to the next milestone as well, so they appear at the top of
-the project board.
+This image shows one release in progress for ``0.15.1`` and another for
+``0.16.0``. Each of these releases has a project board containing issues
+and pull requests. GitHub shows a status bar with completed work in
+green, work in progress in purple, and work not started yet in gray, so
+it's fairly easy to see progress.
 
-Spack's milestones are not firm commitments so we move work between releases frequently. If we
-need to make a release and some tasks are not yet done, we will simply move them to the next major
-release milestone, rather than delaying the release to complete them.
+Spack's project boards are not firm commitments so we move work between
+releases frequently. If we need to make a release and some tasks are not
+yet done, we will simply move them to the next minor or major release, rather
+than delaying the release to complete them.
 
-^^^^^^^^^^^^^^^^^^^^^
-Backporting bug fixes
-^^^^^^^^^^^^^^^^^^^^^
+For more on using GitHub project boards, see `GitHub's documentation
+<https://docs.github.com/en/github/managing-your-work-on-github/about-project-boards>`_.
 
-When a bug is fixed in the ``develop`` branch, it is often necessary to backport the fix to one
-(or more) of the ``release/vX.Y`` branches. Only the release manager is responsible for doing
-backports, but Spack maintainers are responsible for labelling pull requests (and issues if no bug
-fix is available yet) with ``vX.Y.Z`` labels. The label should correspond to the next patch version
-that the bug fix should be backported to.
-
-Backports are done publicly by the release manager using a pull request named ``Backports vX.Y.Z``.
-This pull request is opened from the ``backports/vX.Y.Z`` branch, targets the ``releases/vX.Y``
-branch and contains a (growing) list of cherry-picked commits from the ``develop`` branch.
-Typically there are one or two backport pull requests open at any given time.
 
 .. _major-releases:
 
@@ -811,21 +874,25 @@ Typically there are one or two backport pull requests open at any given time.
 Making major releases
 ^^^^^^^^^^^^^^^^^^^^^
 
-Assuming all required work from the milestone is completed, the steps to make the major release
-are:
+Assuming a project board has already been created and all required work
+completed, the steps to make the major release are:
 
-#. `Create a new milestone <https://github.com/spack/spack/milestones>`_ for the next major
-   release.
+#. Create two new project boards:
 
-#. `Create a new label <https://github.com/spack/spack/labels>`_ for the next patch release.
+   * One for the next major release
+   * One for the next point release
 
-#. Move any optional tasks that are not done to the next milestone.
+#. Move any optional tasks that are not done to one of the new project boards.
+
+   In general, small bugfixes should go to the next point release. Major
+   features, refactors, and changes that could affect concretization should
+   go in the next major release.
 
 #. Create a branch for the release, based on ``develop``:
 
    .. code-block:: console
 
-      $ git checkout -b releases/v0.23 develop
+      $ git checkout -b releases/v0.15 develop
 
    For a version ``vX.Y.Z``, the branch's name should be
    ``releases/vX.Y``. That is, you should create a ``releases/vX.Y``
@@ -861,8 +928,8 @@ are:
 
    Create a pull request targeting the ``develop`` branch, bumping the major
    version in ``lib/spack/spack/__init__.py`` with a ``dev0`` release segment.
-   For instance when you have just released ``v0.23.0``, set the version
-   to ``(0, 24, 0, 'dev0')`` on ``develop``.
+   For instance when you have just released ``v0.15.0``, set the version
+   to ``(0, 16, 0, 'dev0')`` on ``develop``.
 
 #. Follow the steps in :ref:`publishing-releases`.
 
@@ -871,52 +938,82 @@ are:
 #. Follow the steps in :ref:`announcing-releases`.
 
 
-.. _patch-releases:
+.. _point-releases:
 
 ^^^^^^^^^^^^^^^^^^^^^
-Making patch releases
+Making point releases
 ^^^^^^^^^^^^^^^^^^^^^
 
-To make the patch release process both efficient and transparent, we use a *backports pull request*
-which contains cherry-picked commits from the ``develop`` branch. The majority of the work is to
-cherry-pick the bug fixes, which ideally should be done as soon as they land on ``develop``:
-this ensures cherry-picking happens in order, and makes conflicts easier to resolve since the
-changes are fresh in the mind of the developer.
+Assuming a project board has already been created and all required work
+completed, the steps to make the point release are:
 
-The backports pull request is always titled ``Backports vX.Y.Z`` and is labelled ``backports``. It
-is opened from a branch named ``backports/vX.Y.Z`` and targets the ``releases/vX.Y`` branch.
+#. Create a new project board for the next point release.
 
-Whenever a pull request labelled ``vX.Y.Z`` is merged, cherry-pick the associated squashed commit
-on ``develop`` to the ``backports/vX.Y.Z`` branch. For pull requests that were rebased (or not
-squashed), cherry-pick each associated commit individually. Never force push to the
-``backports/vX.Y.Z`` branch.
+#. Move any optional tasks that are not done to the next project board.
 
-.. warning::
+#. Check out the release branch (it should already exist).
 
-   Sometimes you may **still** get merge conflicts even if you have
-   cherry-picked all the commits in order. This generally means there
-   is some other intervening pull request that the one you're trying
-   to pick depends on. In these cases, you'll need to make a judgment
-   call regarding those pull requests.  Consider the number of affected
-   files and/or the resulting differences.
+    For the ``X.Y.Z`` release, the release branch is called ``releases/vX.Y``.
+    For ``v0.15.1``, you would check out ``releases/v0.15``:
 
-   1. If the changes are small, you might just cherry-pick it.
+   .. code-block:: console
 
-   2. If the changes are large, then you may decide that this fix is not
-      worth including in a patch release, in which case you should remove
-      the label from the pull request. Remember that large, manual backports
-      are seldom the right choice for a patch release.
+      $ git checkout releases/v0.15
 
-When all commits are cherry-picked in the ``backports/vX.Y.Z`` branch, make the patch
-release as follows:
+#. If a pull request to the release branch named ``Backports vX.Y.Z`` is not already
+   in the project, create it. This pull request ought to be created as early as
+   possible when working on a release project, so that we can build the release
+   commits incrementally, and identify potential conflicts at an early stage.
 
-#. `Create a new label <https://github.com/spack/spack/labels>`_ ``vX.Y.{Z+1}`` for the next patch
-   release.
+#. Cherry-pick each pull request in the ``Done`` column of the release
+   project board onto the ``Backports vX.Y.Z`` pull request.
 
-#. Replace the label ``vX.Y.Z`` with ``vX.Y.{Z+1}`` for all PRs and issues that are not done.
+   This is **usually** fairly simple since we squash the commits from the
+   vast majority of pull requests. That means there is only one commit
+   per pull request to cherry-pick. For example, `this pull request
+   <https://github.com/spack/spack/pull/15777>`_ has three commits, but
+   they were squashed into a single commit on merge. You can see the
+   commit that was created here:
 
-#. Manually push a single commit with commit message ``Set version to vX.Y.Z`` to the
-   ``backports/vX.Y.Z`` branch, that both bumps the Spack version number and updates the changelog:
+   .. image:: images/pr-commit.png
+
+   You can easily cherry pick it like this (assuming you already have the
+   release branch checked out):
+
+   .. code-block:: console
+
+      $ git cherry-pick 7e46da7
+
+   For pull requests that were rebased (or not squashed), you'll need to
+   cherry-pick each associated commit individually.
+
+   .. warning::
+
+      It is important to cherry-pick commits in the order they happened,
+      otherwise you can get conflicts while cherry-picking. When
+      cherry-picking look at the merge date,
+      **not** the number of the pull request or the date it was opened.
+
+      Sometimes you may **still** get merge conflicts even if you have
+      cherry-picked all the commits in order. This generally means there
+      is some other intervening pull request that the one you're trying
+      to pick depends on. In these cases, you'll need to make a judgment
+      call regarding those pull requests.  Consider the number of affected
+      files and or the resulting differences.
+
+      1. If the dependency changes are small, you might just cherry-pick it,
+         too. If you do this, add the task to the release board.
+
+      2. If the changes are large, then you may decide that this fix is not
+         worth including in a point release, in which case you should remove
+         the task from the release project.
+
+      3. You can always decide to manually back-port the fix to the release
+         branch if neither of the above options makes sense, but this can
+         require a lot of work. It's seldom the right choice.
+
+#. When all the commits from the project board are cherry-picked into
+   the ``Backports vX.Y.Z`` pull request, you can push a commit to:
 
    1. Bump the version in ``lib/spack/spack/__init__.py``.
    2. Update ``CHANGELOG.md`` with a list of the changes.
@@ -925,22 +1022,20 @@ release as follows:
    release branch. See `the changelog from 0.14.1
    <https://github.com/spack/spack/commit/ff0abb9838121522321df2a054d18e54b566b44a>`_.
 
-#. Make sure CI passes on the **backports pull request**, including:
+#. Merge the ``Backports vX.Y.Z`` PR with the **Rebase and merge** strategy. This
+   is needed to keep track in the release branch of all the commits that were
+   cherry-picked.
+
+#. Make sure CI passes on the release branch, including:
 
    * Regular unit tests
    * Build tests
    * The E4S pipeline at `gitlab.spack.io <https://gitlab.spack.io>`_
 
-#. Merge the ``Backports vX.Y.Z`` PR with the **Rebase and merge** strategy. This
-   is needed to keep track in the release branch of all the commits that were
-   cherry-picked.
-
-#. Make sure CI passes on the last commit of the **release branch**.
-
-#. In the rare case you need to include additional commits in the patch release after the backports
-   PR is merged, it is best to delete the last commit ``Set version to vX.Y.Z`` from the release
-   branch with a single force push, open a new backports PR named ``Backports vX.Y.Z (2)``, and
-   repeat the process. Avoid repeated force pushes to the release branch.
+   If CI does not pass, you'll need to figure out why, and make changes
+   to the release branch until it does. You can make more commits, modify
+   or remove cherry-picked commits, or cherry-pick **more** from
+   ``develop`` to make this happen.
 
 #. Follow the steps in :ref:`publishing-releases`.
 
@@ -1015,31 +1110,25 @@ Updating `releases/latest`
 
 If the new release is the **highest** Spack release yet, you should
 also tag it as ``releases/latest``. For example, suppose the highest
-release is currently ``0.22.3``:
+release is currently ``0.15.3``:
 
-* If you are releasing ``0.22.4`` or ``0.23.0``, then you should tag
-  it with ``releases/latest``, as these are higher than ``0.22.3``.
+* If you are releasing ``0.15.4`` or ``0.16.0``, then you should tag
+  it with ``releases/latest``, as these are higher than ``0.15.3``.
 
 * If you are making a new release of an **older** major version of
-  Spack, e.g. ``0.21.4``, then you should not tag it as
+  Spack, e.g. ``0.14.4``, then you should not tag it as
   ``releases/latest`` (as there are newer major versions).
 
-To do so, first fetch the latest tag created on GitHub, since you may not have it locally:
+To tag ``releases/latest``, do this:
 
 .. code-block:: console
 
-   $ git fetch --force git@github.com:spack/spack vX.Y.Z
+   $ git checkout releases/vX.Y     # vX.Y is the new release's branch
+   $ git tag --force releases/latest
+   $ git push --force --tags
 
-Then tag ``vX.Y.Z`` as ``releases/latest`` and push the individual tag to GitHub.
-
-.. code-block:: console
-
-   $ git tag --force releases/latest vX.Y.Z
-   $ git push --force git@github.com:spack/spack releases/latest
-
-The ``--force`` argument to ``git tag`` makes ``git`` overwrite the existing ``releases/latest``
-tag with the new one. Do **not** use the ``--tags`` flag when pushing, since this will push *all*
-local tags.
+The ``--force`` argument to ``git tag`` makes ``git`` overwrite the existing
+``releases/latest`` tag with the new one.
 
 
 .. _announcing-releases:
@@ -1050,9 +1139,9 @@ Announcing a release
 
 We announce releases in all of the major Spack communication channels.
 Publishing the release takes care of GitHub. The remaining channels are
-X, Slack, and the mailing list. Here are the steps:
+Twitter, Slack, and the mailing list. Here are the steps:
 
-#. Announce the release on X.
+#. Announce the release on Twitter.
 
    * Compose the tweet on the ``@spackpm`` account per the
      ``spack-twitter`` slack channel.

lib/spack/docs/environments.rst

@@ -5,56 +5,49 @@
 
 .. _environments:
 
-=====================================
-Environments (spack.yaml, spack.lock)
-=====================================
+=========================
+Environments (spack.yaml)
+=========================
 
-An environment is used to group a set of specs intended for some purpose
-to be built, rebuilt, and deployed in a coherent fashion. Environments
-define aspects of the installation of the software, such as:
+An environment is used to group together a set of specs for the
+purpose of building, rebuilding and deploying in a coherent fashion.
+Environments provide a number of advantages over the *à la carte*
+approach of building and loading individual Spack modules:
 
-#. *which* specs to install;
-#. *how* those specs are configured; and
-#. *where* the concretized software will be installed.
-
-Aggregating this information into an environment for processing has advantages
-over the *à la carte* approach of building and loading individual Spack modules.
-
-With environments, you concretize, install, or load (activate) all of the
-specs with a single command. Concretization fully configures the specs
-and dependencies of the environment in preparation for installing the
-software. This is a more robust solution than ad-hoc installation scripts.
-And you can share an environment or even re-use it on a different computer.
-
-Environment definitions, especially *how* specs are configured, allow the
-software to remain stable and repeatable even when Spack packages are upgraded. Changes are only picked up when the environment is explicitly re-concretized.
-
-Defining *where* specs are installed supports a filesystem view of the
-environment. Yet Spack maintains a single installation of the software that
-can be re-used across multiple environments.
-
-Activating an environment determines *when* all of the associated (and
-installed) specs are loaded so limits the software loaded to those specs
-actually needed by the environment. Spack can even generate a script to
-load all modules related to an environment.
+#. Environments separate the steps of (a) choosing what to
+   install, (b) concretizing, and (c) installing.  This allows
+   Environments to remain stable and repeatable, even if Spack packages
+   are upgraded: specs are only re-concretized when the user
+   explicitly asks for it.  It is even possible to reliably
+   transport environments between different computers running
+   different versions of Spack!
+#. Environments allow several specs to be built at once; a more robust
+   solution than ad-hoc scripts making multiple calls to ``spack
+   install``.
+#. An Environment that is built as a whole can be loaded as a whole
+   into the user environment. An Environment can be built to maintain
+   a filesystem view of its packages, and the environment can load
+   that view into the user environment at activation time. Spack can
+   also generate a script to load all modules related to an
+   environment.
 
 Other packaging systems also provide environments that are similar in
 some ways to Spack environments; for example, `Conda environments
 <https://conda.io/docs/user-guide/tasks/manage-environments.html>`_ or
 `Python Virtual Environments
 <https://docs.python.org/3/tutorial/venv.html>`_.  Spack environments
-provide some distinctive features though:
+provide some distinctive features:
 
 #. A spec installed "in" an environment is no different from the same
-   spec installed anywhere else in Spack.
-#. Spack environments may contain more than one spec of the same
+   spec installed anywhere else in Spack.  Environments are assembled
+   simply by collecting together a set of specs.
+#. Spack Environments may contain more than one spec of the same
    package.
 
 Spack uses a "manifest and lock" model similar to `Bundler gemfiles
-<https://bundler.io/man/gemfile.5.html>`_ and other package managers.
-The environment's user input file (or manifest), is named ``spack.yaml``.
-The lock file, which contains the fully configured and concretized specs,
-is named ``spack.lock``.
+<https://bundler.io/man/gemfile.5.html>`_ and other package
+managers. The user input file is named ``spack.yaml`` and the lock
+file is named ``spack.lock``
 
 .. _environments-using:
 
@@ -75,60 +68,55 @@ An environment is created by:
 
    $ spack env create myenv
 
-The directory ``$SPACK_ROOT/var/spack/environments/myenv`` is created
-to manage the environment.
+Spack then creates the directory ``var/spack/environments/myenv``.
 
 .. note::
 
-   All managed environments by default are stored in the
-   ``$SPACK_ROOT/var/spack/environments`` folder. This location can be changed
-   by setting the ``environments_root`` variable in ``config.yaml``.
+   All managed environments by default are stored in the ``var/spack/environments`` folder.
+   This location can be changed by setting the ``environments_root`` variable in ``config.yaml``.
 
-Spack creates the file ``spack.yaml``, hidden directory ``.spack-env``, and
-``spack.lock`` file under ``$SPACK_ROOT/var/spack/environments/myenv``. User
-interaction occurs through the ``spack.yaml`` file and the Spack commands
-that affect it. Metadata and, by default, the view are stored in the
-``.spack-env`` directory. When the environment is concretized, Spack creates
-the ``spack.lock`` file with the fully configured specs and dependencies for
+In the ``var/spack/environments/myenv`` directory, Spack creates the
+file ``spack.yaml`` and the hidden directory ``.spack-env``.
+
+Spack stores metadata in the ``.spack-env`` directory. User
+interaction will occur through the ``spack.yaml`` file and the Spack
+commands that affect it. When the environment is concretized, Spack
+will create a file ``spack.lock`` with the concrete information for
 the environment.
 
-The ``.spack-env`` subdirectory also contains:
+In addition to being the default location for the view associated with
+an Environment, the ``.spack-env`` directory also contains:
 
-  * ``repo/``: A subdirectory acting as the repo consisting of the Spack
-    packages used in the environment. It allows the environment to build
-    the same, in theory, even on different versions of Spack with different
+  * ``repo/``: A repo consisting of the Spack packages used in this
+    environment.  This allows the environment to build the same, in
+    theory, even on different versions of Spack with different
     packages!
-  * ``logs/``: A subdirectory containing the build logs for the packages
-    in this environment.
+  * ``logs/``: A directory containing the build logs for the packages
+    in this Environment.
 
-Spack Environments can also be created from either the user input, or
-manifest, file or the lockfile. Create an environment from a manifest using:
+Spack Environments can also be created from either a manifest file
+(usually but not necessarily named, ``spack.yaml``) or a lockfile.
+To create an Environment from a manifest:
 
 .. code-block:: console
 
    $ spack env create myenv spack.yaml
 
-The resulting environment is guaranteed to have the same root specs as
-the original but may concretize differently in the presence of different
-explicit or default configuration settings (e.g., a different version of
-Spack or for a different user account).
-
-Create an environment from a ``spack.lock`` file using:
+To create an Environment from a ``spack.lock`` lockfile:
 
 .. code-block:: console
 
    $ spack env create myenv spack.lock
 
-The resulting environment, when on the same or a compatible machine, is
-guaranteed to initially have the same concrete specs as the original.
+Either of these commands can also take a full path to the
+initialization file.
 
-.. note::
-
-   Environment creation also accepts a full path to the file.
-
-   If the path is not under the ``$SPACK_ROOT/var/spack/environments``
-   directory then the source is referred to as an
-   :ref:`independent environment <independent_environments>`.
+A Spack Environment created from a ``spack.yaml`` manifest is
+guaranteed to have the same root specs as the original Environment,
+but may concretize differently. A Spack Environment created from a
+``spack.lock`` lockfile is guaranteed to have the same concrete specs
+as the original Environment. Either may obviously then differ as the
+user modifies it.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Activating an Environment
@@ -141,7 +129,7 @@ To activate an environment, use the following command:
    $ spack env activate myenv
 
 By default, the ``spack env activate`` will load the view associated
-with the environment into the user environment. The ``-v,
+with the Environment into the user environment. The ``-v,
 --with-view`` argument ensures this behavior, and the ``-V,
 --without-view`` argument activates the environment without changing
 the user environment variables.
@@ -154,20 +142,6 @@ user's prompt to begin with the environment name in brackets.
    $ spack env activate -p myenv
    [myenv] $ ...
 
-The ``activate`` command can also be used to create a new environment, if it is
-not already defined, by adding the ``--create`` flag. Managed and independent
-environments can both be created using the same flags that `spack env create`
-accepts.  If an environment already exists then spack will simply activate it
-and ignore the create-specific flags.
-
-.. code-block:: console
-   
-   $ spack env activate --create -p myenv
-   # ...
-   # [creates if myenv does not exist yet]
-   # ...
-   [myenv] $ ...
-
 To deactivate an environment, use the command:
 
 .. code-block:: console
@@ -183,50 +157,34 @@ or the shortcut alias
 If the environment was activated with its view, deactivating the
 environment will remove the view from the user environment.
 
-.. _independent_environments:
+^^^^^^^^^^^^^^^^^^^^^^
+Anonymous Environments
+^^^^^^^^^^^^^^^^^^^^^^
 
-^^^^^^^^^^^^^^^^^^^^^^^^
-Independent Environments
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Independent environments can be located in any directory outside of Spack.
-
-.. note::
-
-   When uninstalling packages, Spack asks the user to confirm the removal of packages
-   that are still used in a managed environment. This is not the case for independent
-   environments.
-
-To create an independent environment, use one of the following commands:
+Any directory can be treated as an environment if it contains a file
+``spack.yaml``. To load an anonymous environment, use:
 
 .. code-block:: console
 
-   $ spack env create --dir my_env
-   $ spack env create ./my_env
+   $ spack env activate -d /path/to/directory
 
-As a shorthand, you can also create an independent environment upon activation if it does not
-already exist:
+Anonymous specs can be created in place using the command:
 
 .. code-block:: console
 
-   $ spack env activate --create ./my_env
+   $ spack env create -d .
 
-For convenience, Spack can also place an independent environment in a temporary directory for you:
+In this case Spack simply creates a ``spack.yaml`` file in the requested
+directory.
 
-.. code-block:: console
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Environment Sensitive Commands
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-   $ spack env activate --temp
-
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Environment-Aware Commands
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Spack commands are environment-aware. For example, the ``find``
-command shows only the specs in the active environment if an
-environment has been activated. Otherwise it shows all specs in
-the Spack instance. The same rule applies to the ``install`` and
-``uninstall`` commands.
+Spack commands are environment sensitive. For example, the ``find``
+command shows only the specs in the active Environment if an
+Environment has been activated. Similarly, the ``install`` and
+``uninstall`` commands act on the active environment.
 
 .. code-block:: console
 
@@ -271,33 +229,32 @@ the Spack instance. The same rule applies to the ``install`` and
 
 
 Note that when we installed the abstract spec ``zlib@1.2.8``, it was
-presented as a root of the environment. All explicitly installed
-packages will be listed as roots of the environment.
+presented as a root of the Environment. All explicitly installed
+packages will be listed as roots of the Environment.
 
 All of the Spack commands that act on the list of installed specs are
-environment-aware in this way, including ``install``,
-``uninstall``, ``find``, ``extensions``, etcetera. In the
+Environment-sensitive in this way, including ``install``,
+``uninstall``, ``find``, ``extensions``, and more. In the
 :ref:`environment-configuration` section we will discuss
-environment-aware commands further.
+Environment-sensitive commands further.
 
 ^^^^^^^^^^^^^^^^^^^^^
 Adding Abstract Specs
 ^^^^^^^^^^^^^^^^^^^^^
 
-An abstract spec is the user-specified spec before Spack applies
-defaults or dependency information.
+An abstract spec is the user-specified spec before Spack has applied
+any defaults or dependency information.
 
-Users can add abstract specs to an environment using the ``spack add``
-command. The most important component of an environment is a list of
+Users can add abstract specs to an Environment using the ``spack add``
+command. The most important component of an Environment is a list of
 abstract specs.
 
-Adding a spec adds it as a root spec of the environment in the user
-input file (``spack.yaml``). It does not affect the concrete specs
-in the lock file (``spack.lock``) and it does not install the spec.
+Adding a spec adds to the manifest (the ``spack.yaml`` file), which is
+used to define the roots of the Environment, but does not affect the
+concrete specs in the lockfile, nor does it install the spec.
 
-The ``spack add`` command is environment-aware. It adds the spec to the
-currently active environment. An error is generated if there isn't an
-active environment. All environment-aware commands can also
+The ``spack add`` command is environment aware. It adds to the
+currently active environment. All environment aware commands can also
 be called using the ``spack -e`` flag to specify the environment.
 
 .. code-block:: console
@@ -317,11 +274,11 @@ or
 Concretizing
 ^^^^^^^^^^^^
 
-Once user specs have been added to an environment, they can be concretized.
-There are three different modes of operation to concretize an environment,
-explained in detail in :ref:`environments_concretization_config`.
-Regardless of which mode of operation is chosen, the following
-command will ensure all of the root specs are concretized according to the
+Once some user specs have been added to an environment, they can be concretized.
+There are at the moment three different modes of operation to concretize an environment,
+which are explained in details in :ref:`environments_concretization_config`.
+Regardless of which mode of operation has been chosen, the following
+command will ensure all the root specs are concretized according to the
 constraints that are prescribed in the configuration:
 
 .. code-block:: console
@@ -330,15 +287,16 @@ constraints that are prescribed in the configuration:
 
 In the case of specs that are not concretized together, the command
 above will concretize only the specs that were added and not yet
-concretized. Forcing a re-concretization of all of the specs can be done
-by adding the ``-f`` option:
+concretized. Forcing a re-concretization of all the specs can be done
+instead with this command:
 
 .. code-block:: console
 
    [myenv]$ spack concretize -f
 
-Without the option, Spack guarantees that already concretized specs are
-unchanged in the environment.
+When the ``-f`` flag is not used to reconcretize all specs, Spack
+guarantees that already concretized specs are unchanged in the
+environment.
 
 The ``concretize`` command does not install any packages. For packages
 that have already been installed outside of the environment, the
@@ -371,16 +329,16 @@ installed specs using the ``-c`` (``--concretized``) flag.
 Installing an Environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In addition to adding individual specs to an environment, one
-can install the entire environment at once using the command
+In addition to installing individual specs into an Environment, one
+can install the entire Environment at once using the command
 
 .. code-block:: console
 
    [myenv]$ spack install
 
-If the environment has been concretized, Spack will install the
-concretized specs. Otherwise, ``spack install`` will concretize
-the environment before installing the concretized specs.
+If the Environment has been concretized, Spack will install the
+concretized specs. Otherwise, ``spack install`` will first concretize
+the Environment and then install the concretized specs.
 
 .. note::
 
@@ -401,17 +359,17 @@ the environment before installing the concretized specs.
 
 
 As it installs, ``spack install`` creates symbolic links in the
-``logs/`` directory in the environment, allowing for easy inspection
+``logs/`` directory in the Environment, allowing for easy inspection
 of build logs related to that environment. The ``spack install``
 command also stores a Spack repo containing the ``package.py`` file
 used at install time for each package in the ``repos/`` directory in
-the environment.
+the Environment.
 
 The ``--no-add`` option can be used in a concrete environment to tell
 spack to install specs already present in the environment but not to
 add any new root specs to the environment.  For root specs provided
 to ``spack install`` on the command line, ``--no-add`` is the default,
-while for dependency specs, it is optional.  In other
+while for dependency specs on the other hand, it is optional.  In other
 words, if there is an unambiguous match in the active concrete environment
 for a root spec provided to ``spack install`` on the command line, spack
 does not require you to specify the ``--no-add`` option to prevent the spec
@@ -425,22 +383,12 @@ Developing Packages in a Spack Environment
 
 The ``spack develop`` command allows one to develop Spack packages in
 an environment. It requires a spec containing a concrete version, and
-will configure Spack to install the package from local source. 
-If a version is not provided from the command line interface then spack 
-will automatically pick the highest version the package has defined.
-This means any infinity versions (``develop``, ``main``, ``stable``) will be
-preferred in this selection process.
-By default, ``spack develop`` will also clone the package to a subdirectory in the
-environment for the local source. This package will have a special variant ``dev_path``
+will configure Spack to install the package from local source. By
+default, it will also clone the package to a subdirectory in the
+environment. This package will have a special variant ``dev_path``
 set, and Spack will ensure the package and its dependents are rebuilt
 any time the environment is installed if the package's local source
-code has been modified. Spack's native implementation to check for modifications
-is to check if ``mtime`` is newer than the installation.
-A custom check can be created by overriding the ``detect_dev_src_change`` method 
-in your package class. This is particularly useful for projects using custom spack repo's 
-to drive development and want to optimize performance. 
-
-Spack ensures that all instances of a
+code has been modified. Spack ensures that all instances of a
 developed package in the environment are concretized to match the
 version (and other constraints) passed as the spec argument to the
 ``spack develop`` command.
@@ -450,26 +398,9 @@ also be used as valid concrete versions (see :ref:`version-specifier`).
 This means that for a package ``foo``, ``spack develop foo@git.main`` will clone
 the ``main`` branch of the package, and ``spack install`` will install from
 that git clone if ``foo`` is in the environment.
-Further development on ``foo`` can be tested by re-installing the environment,
+Further development on ``foo`` can be tested by reinstalling the environment,
 and eventually committed and pushed to the upstream git repo.
 
-If the package being developed supports out-of-source builds then users can use the
-``--build_directory`` flag to control the location and name of the build directory. 
-This is a shortcut to set the ``package_attributes:build_directory`` in the
-``packages`` configuration (see :ref:`assigning-package-attributes`).
-The supplied location will become the build-directory for that package in all future builds.
-
-.. warning::
-   Potential pitfalls of setting the build directory
-    Spack does not check for out-of-source build compatibility with the packages and
-    so the onerous of making sure the package supports out-of-source builds is on
-    the user.
-    For example, most ``autotool`` and ``makefile`` packages do not support out-of-source builds
-    while all ``CMake`` packages do.
-    Understanding these nuances are on the software developers and we strongly encourage
-    developers to only redirect the build directory if they understand their package's
-    build-system.
-
 ^^^^^^^
 Loading
 ^^^^^^^
@@ -486,125 +417,6 @@ Sourcing that file in Bash will make the environment available to the
 user; and can be included in ``.bashrc`` files, etc.  The ``loads``
 file may also be copied out of the environment, renamed, etc.
 
-
-.. _environment_include_concrete:
-
-------------------------------
-Included Concrete Environments
-------------------------------
-
-Spack environments can create an environment based off of information in already
-established environments. You can think of it as a combination of existing
-environments. It will gather information from the existing environment's
-``spack.lock`` and use that during the creation of this included concrete
-environment. When an included concrete environment is created it will generate
-a ``spack.lock`` file for the newly created environment.
-
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Creating included environments
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To create a combined concrete environment, you must have at least one existing
-concrete environment. You will use the command ``spack env create`` with the
-argument ``--include-concrete`` followed by the name or path of the environment
-you'd like to include. Here is an example of how to create a combined environment
-from the command line.
-
-.. code-block:: console
-
-   $ spack env create myenv
-   $ spack -e myenv add python
-   $ spack -e myenv concretize
-   $ spack env create --include-concrete myenv included_env
-
-
-You can also include an environment directly in the ``spack.yaml`` file. It
-involves adding the ``include_concrete`` heading in the yaml followed by the
-absolute path to the independent environments.
-
-.. code-block:: yaml
-
-   spack:
-     specs: []
-     concretizer:
-         unify: true
-     include_concrete:
-     - /absolute/path/to/environment1
-     - /absolute/path/to/environment2
-
-
-Once the ``spack.yaml`` has been updated you must concretize the environment to
-get the concrete specs from the included environments.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Updating an included environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-If changes were made to the base environment and you want that reflected in the
-included environment you will need to reconcretize both the base environment and the
-included environment for the change to be implemented. For example:
-
-.. code-block:: console
-
-   $ spack env create myenv
-   $ spack -e myenv add python
-   $ spack -e myenv concretize
-   $ spack env create --include-concrete myenv included_env
-
-
-   $ spack -e myenv find
-   ==> In environment myenv
-   ==> Root specs
-   python
-
-   ==> 0 installed packages
-
-
-   $ spack -e included_env find
-   ==> In environment included_env
-   ==> No root specs
-   ==> Included specs
-   python
-
-   ==> 0 installed packages
-
-Here we see that ``included_env`` has access to the python package through
-the ``myenv`` environment. But if we were to add another spec to ``myenv``,
-``included_env`` will not be able to access the new information.
-
-.. code-block:: console
-
-   $ spack -e myenv add perl
-   $ spack -e myenv concretize
-   $ spack -e myenv find
-   ==> In environment myenv
-   ==> Root specs
-   perl  python
-
-   ==> 0 installed packages
-
-
-   $ spack -e included_env find
-   ==> In environment included_env
-   ==> No root specs
-   ==> Included specs
-   python
-
-   ==> 0 installed packages
-
-It isn't until you run the ``spack concretize`` command that the combined
-environment will get the updated information from the reconcretized base environmennt.
-
-.. code-block:: console
-
-   $ spack -e included_env concretize
-   $ spack -e included_env find
-   ==> In environment included_env
-   ==> No root specs
-   ==> Included specs
-   perl  python
-
-   ==> 0 installed packages
-
 .. _environment-configuration:
 
 ------------------------
@@ -635,7 +447,7 @@ manipulate configuration inline in the ``spack.yaml`` file.
 Inline configurations
 ^^^^^^^^^^^^^^^^^^^^^
 
-Inline environment-scope configuration is done using the same yaml
+Inline Environment-scope configuration is done using the same yaml
 format as standard Spack configuration scopes, covered in the
 :ref:`configuration` section. Each section is contained under a
 top-level yaml object with it's name. For example, a ``spack.yaml``
@@ -645,11 +457,11 @@ a ``packages.yaml`` file) could contain:
 .. code-block:: yaml
 
    spack:
-     # ...
+     ...
      packages:
        all:
          compiler: [intel]
-     # ...
+     ...
 
 This configuration sets the default compiler for all packages to
 ``intel``.
@@ -660,7 +472,7 @@ Included configurations
 
 Spack environments allow an ``include`` heading in their yaml
 schema. This heading pulls in external configuration files and applies
-them to the environment.
+them to the Environment.
 
 .. code-block:: yaml
 
@@ -673,9 +485,6 @@ them to the environment.
 Environments can include files or URLs. File paths can be relative or
 absolute. URLs include the path to the text for individual files or
 can be the path to a directory containing configuration files.
-Spack supports ``file``, ``http``, ``https`` and ``ftp`` protocols (or
-schemes). Spack-specific, environment and user path variables may be
-used in these paths. See :ref:`config-file-variables` for more information.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^
 Configuration precedence
@@ -690,7 +499,7 @@ have higher precedence, as the included configs are applied in reverse order.
 Manually Editing the Specs List
 -------------------------------
 
-The list of abstract/root specs in the environment is maintained in
+The list of abstract/root specs in the Environment is maintained in
 the ``spack.yaml`` manifest under the heading ``specs``.
 
 .. code-block:: yaml
@@ -798,7 +607,7 @@ evaluates to the cross-product of those specs. Spec matrices also
 contain an ``excludes`` directive, which eliminates certain
 combinations from the evaluated result.
 
-The following two environment manifests are identical:
+The following two Environment manifests are identical:
 
 .. code-block:: yaml
 
@@ -873,7 +682,7 @@ files are identical.
 In short files like the example, it may be easier to simply list the
 included specs. However for more complicated examples involving many
 packages across many toolchains, separately factored lists make
-environments substantially more manageable.
+Environments substantially more manageable.
 
 Additionally, the ``-l`` option to the ``spack add`` command allows
 one to add to named lists in the definitions section of the manifest
@@ -892,7 +701,7 @@ named list ``compilers`` is ``['%gcc', '%clang', '%intel']`` on
    spack:
      definitions:
        - compilers: ['%gcc', '%clang']
-       - when: arch.satisfies('target=x86_64:')
+       - when: arch.satisfies('x86_64:')
          compilers: ['%intel']
 
 .. note::
@@ -959,90 +768,37 @@ For example, the following environment has three root packages:
 This allows for a much-needed reduction in redundancy between packages
 and constraints.
 
+----------------
+Filesystem Views
+----------------
 
------------------
-Environment Views
------------------
-
-Spack Environments can have an associated filesystem view, which is a directory
-with a more traditional structure ``<view>/bin``, ``<view>/lib``, ``<view>/include``
-in which all files of the installed packages are linked.
-
-By default a view is created for each environment, thanks to the ``view: true``
-option in the ``spack.yaml`` manifest file:
-
-.. code-block:: yaml
-
-   spack:
-     specs: [perl, python]
-     view: true
-
-The view is created in a hidden directory ``.spack-env/view`` relative to the environment.
-If you've used ``spack env activate``, you may have already interacted with this view. Spack
-prepends its ``<view>/bin`` dir to ``PATH`` when the environment is activated, so that
-you can directly run executables from all installed packages in the environment.
-
-Views are highly customizable: you can control where they are put, modify their structure,
-include and exclude specs, change how files are linked, and you can even generate multiple
-views for a single environment.
+Spack Environments can define filesystem views, which provide a direct access point
+for software similar to the directory hierarchy that might exist under ``/usr/local``.
+Filesystem views are updated every time the environment is written out to the lock
+file ``spack.lock``, so the concrete environment and the view are always compatible.
+The files of the view's installed packages are brought into the view by symbolic or
+hard links, referencing the original Spack installation, or by copy.
 
 .. _configuring_environment_views:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Minimal view configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Configuration in ``spack.yaml``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The minimal configuration
-
-.. code-block:: yaml
-
-   spack:
-     # ...
-     view: true
-
-lets Spack generate a single view with default settings under the
-``.spack-env/view`` directory of the environment.
-
-Another short way to configure a view is to specify just where to put it:
-
-.. code-block:: yaml
-
-   spack:
-     # ...
-     view: /path/to/view
-
-Views can also be disabled by setting ``view: false``.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Advanced view configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-One or more **view descriptors** can be defined under ``view``, keyed by a name.
-The example from the previous section with ``view: /path/to/view`` is equivalent
-to defining a view descriptor named ``default`` with a ``root`` attribute:
-
-.. code-block:: yaml
-
-   spack:
-     # ...
-     view:
-       default:  # name of the view
-         root: /path/to/view  # view descriptor attribute
-
-The ``default`` view descriptor name is special: when you ``spack env activate`` your
-environment, this view will be used to update (among other things) your ``PATH``
-variable.
-
-View descriptors must contain the root of the view, and optionally projections,
-``select`` and ``exclude`` lists and link information via ``link`` and
+The Spack Environment manifest file has a top-level keyword
+``view``. Each entry under that heading is a **view descriptor**, headed
+by a name. Any number of views may be defined under the ``view`` heading.
+The view descriptor contains the root of the view, and
+optionally the projections for the view, ``select`` and
+``exclude`` lists for the view and link information via ``link`` and
 ``link_type``.
 
-As a more advanced example, in the following manifest
+For example, in the following manifest
 file snippet we define a view named ``mpis``, rooted at
 ``/path/to/view`` in which all projections use the package name,
 version, and compiler name to determine the path for a given
 package. This view selects all packages that depend on MPI, and
-excludes those built with the GCC compiler at version 18.5.
+excludes those built with the PGI compiler at version 18.5.
 The root specs with their (transitive) link and run type dependencies
 will be put in the view due to the  ``link: all`` option,
 and the files in the view will be symlinks to the spack install
@@ -1051,12 +807,12 @@ directories.
 .. code-block:: yaml
 
    spack:
-     # ...
+     ...
      view:
        mpis:
          root: /path/to/view
          select: [^mpi]
-         exclude: ['%gcc@18.5']
+         exclude: ['%pgi@18.5']
          projections:
            all: '{name}/{version}-{compiler.name}'
          link: all
@@ -1082,14 +838,63 @@ of ``hardlink`` or ``copy``.
    when the environment is not activated, and linked libraries will be located
    *outside* of the view thanks to rpaths.
 
+
+There are two shorthands for environments with a single view. If the
+environment at ``/path/to/env`` has a single view, with a root at
+``/path/to/env/.spack-env/view``, with default selection and exclusion
+and the default projection, we can put ``view: True`` in the
+environment manifest. Similarly, if the environment has a view with a
+different root, but default selection, exclusion, and projections, the
+manifest can say ``view: /path/to/view``. These views are
+automatically named ``default``, so that
+
+.. code-block:: yaml
+
+   spack:
+     ...
+     view: True
+
+is equivalent to
+
+.. code-block:: yaml
+
+   spack:
+     ...
+     view:
+       default:
+         root: .spack-env/view
+
+and
+
+.. code-block:: yaml
+
+   spack:
+     ...
+     view: /path/to/view
+
+is equivalent to
+
+.. code-block:: yaml
+
+   spack:
+     ...
+     view:
+       default:
+         root: /path/to/view
+
+By default, Spack environments are configured with ``view: True`` in
+the manifest. Environments can be configured without views using
+``view: False``. For backwards compatibility reasons, environments
+with no ``view`` key are treated the same as ``view: True``.
+
 From the command line, the ``spack env create`` command takes an
 argument ``--with-view [PATH]`` that sets the path for a single, default
 view. If no path is specified, the default path is used (``view:
-true``). The argument ``--without-view`` can be used to create an
+True``). The argument ``--without-view`` can be used to create an
 environment without any view configured.
 
 The ``spack env view`` command can be used to change the manage views
-of an environment. The subcommand ``spack env view enable`` will add a
+of an Environment. The subcommand ``spack env view enable`` will add a
 view named ``default`` to an environment. It takes an optional
 argument to specify the path for the new default view. The subcommand
 ``spack env view disable`` will remove the view named ``default`` from
@@ -1115,17 +920,6 @@ function, as shown in the example below:
      ^mpi: "{name}-{version}/{^mpi.name}-{^mpi.version}-{compiler.name}-{compiler.version}"
      all: "{name}-{version}/{compiler.name}-{compiler.version}"
 
-Projections also permit environment and spack configuration variable
-expansions as shown below:
-
-.. code-block:: yaml
-
-   projections:
-     all: "{name}-{version}/{compiler.name}-{compiler.version}/$date/$SYSTEM_ENV_VARIBLE"
-
-where ``$date`` is the spack configuration variable that will expand with the ``YYYY-MM-DD``
-format and ``$SYSTEM_ENV_VARIABLE`` is an environment variable defined in the shell.
-
 The entries in the projections configuration file must all be either
 specs or the keyword ``all``. For each spec, the projection used will
 be the first non-``all`` entry that the spec satisfies, or ``all`` if
@@ -1151,18 +945,11 @@ the projection under ``all`` before reaching those entries.
 Activating environment views
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The ``spack env activate <env>`` has two effects:
-
-1. It activates the environment so that further Spack commands such
-   as ``spack install`` will run in the context of the environment.
-2. It activates the view so that environment variables such as
-   ``PATH`` are updated to include the view.
-
-Without further arguments, the ``default`` view of the environment is
-activated. If a view with a different name has to be activated,
-``spack env activate --with-view <name> <env>`` can be
-used instead. You can also activate the environment without modifying
-further environment variables using ``--without-view``.
+The ``spack env activate`` command will put the default view for the
+environment into the user's path, in addition to activating the
+environment for Spack commands. The arguments ``-v,--with-view`` and
+``-V,--without-view`` can be used to tune this behavior. The default
+behavior is to activate with the environment view if there is one.
 
 The environment variables affected by the ``spack env activate``
 command and the paths that are used to update them are determined by
@@ -1185,8 +972,8 @@ relevant variable if the path exists. For this reason, it is not
 recommended to use non-default projections with the default view of an
 environment.
 
-The ``spack env deactivate`` command will remove the active view of
-the Spack environment from the user's environment variables.
+The ``spack env deactivate`` command will remove the default view of
+the environment from the user's path.
 
 
 .. _env-generate-depfile:
@@ -1203,7 +990,7 @@ other targets to depend on the environment installation.
 
 A typical workflow is as follows:
 
-.. code-block:: console
+.. code:: console
 
    spack env create -d .
    spack -e . add perl
@@ -1257,7 +1044,7 @@ gets installed and is available for use in the ``env`` target.
    	$(SPACK) -e . env depfile -o $@ --make-prefix spack
 
    env: spack/env
-   	$(info environment installed!)
+   	$(info Environment installed!)
 
    clean:
    	rm -rf spack.lock env.mk spack/
@@ -1296,7 +1083,7 @@ its dependencies. This can be useful when certain flags should only apply to
 dependencies. Below we show a use case where a spec is installed with verbose
 output (``spack install --verbose``) while its dependencies are installed silently:
 
-.. code-block:: console
+.. code:: console
 
    $ spack env depfile -o Makefile
 
@@ -1318,7 +1105,7 @@ This can be accomplished through the generated ``[<prefix>/]SPACK_PACKAGE_IDS``
 variable. Assuming we have an active and concrete environment, we generate the
 associated ``Makefile`` with a prefix ``example``:
 
-.. code-block:: console
+.. code:: console
 
    $ spack env depfile -o env.mk --make-prefix example
 
@@ -1345,7 +1132,7 @@ index once every package is pushed. Note how this target uses the generated
    example/push/%: example/install/%
    	@mkdir -p $(dir $@)
    	$(info About to push $(SPEC) to a buildcache)
-   	$(SPACK) -e . buildcache push --only=package $(BUILDCACHE_DIR) /$(HASH)
+   	$(SPACK) -e . buildcache push --allow-root --only=package $(BUILDCACHE_DIR) /$(HASH)
    	@touch $@
 
    push: $(addprefix example/push/,$(example/SPACK_PACKAGE_IDS))

lib/spack/docs/extensions.rst

@@ -111,39 +111,3 @@ The corresponding unit tests can be run giving the appropriate options to ``spac
 
    (5 durations < 0.005s hidden.  Use -vv to show these durations.)
    =========================================== 5 passed in 5.06s ============================================
-
----------------------------------------
-Registering Extensions via Entry Points
----------------------------------------
-
-.. note::
-   Python version >= 3.8 is required to register extensions via entry points.
-
-Spack can be made aware of extensions that are installed as part of a python package.  To do so, register a function that returns the extension path, or paths, to the ``"spack.extensions"`` entry point.  Consider the Python package ``my_package`` that includes a Spack extension:
-
-.. code-block:: console
-
-  my-package/
-  ├── src
-  │   ├── my_package
-  │   │   └── __init__.py
-  │   └── spack-scripting/  # the spack extensions
-  └── pyproject.toml
-
-adding the following to ``my_package``'s ``pyproject.toml`` will make the ``spack-scripting`` extension visible to Spack when ``my_package`` is installed:
-
-.. code-block:: toml
-
-   [project.entry_points."spack.extenions"]
-   my_package = "my_package:get_extension_path"
-
-The function ``my_package.get_extension_path`` in ``my_package/__init__.py`` might look like
-
-.. code-block:: python
-
-   import importlib.resources
-
-   def get_extension_path():
-       dirname = importlib.resources.files("my_package").joinpath("spack-scripting")
-       if dirname.exists():
-           return str(dirname)

lib/spack/docs/getting_started.rst

@@ -35,7 +35,7 @@ A build matrix showing which packages are working on which systems is shown belo
       .. code-block:: console
 
          apt update
-         apt install bzip2 ca-certificates file g++ gcc gfortran git gzip lsb-release patch python3 tar unzip xz-utils zstd
+         apt install build-essential ca-certificates coreutils curl environment-modules gfortran git gpg lsb-release python3 python3-distutils python3-venv unzip zip
 
    .. tab-item:: RHEL
 
@@ -43,14 +43,14 @@ A build matrix showing which packages are working on which systems is shown belo
 
          dnf install epel-release
          dnf group install "Development Tools"
-         dnf install gcc-gfortran redhat-lsb-core python3 unzip
+         dnf install curl findutils gcc-gfortran gnupg2 hostname iproute redhat-lsb-core python3 python3-pip python3-setuptools unzip python3-boto3
 
    .. tab-item:: macOS Brew
 
       .. code-block:: console
 
          brew update
-         brew install gcc git zip
+         brew install curl gcc git gnupg zip
 
 ------------
 Installation
@@ -61,15 +61,10 @@ Getting Spack is easy.  You can clone it from the `github repository
 
 .. code-block:: console
 
-   $ git clone -c feature.manyFiles=true --depth=2 https://github.com/spack/spack.git
+   $ git clone -c feature.manyFiles=true https://github.com/spack/spack.git
 
 This will create a directory called ``spack``.
 
-.. note::
-   ``-c feature.manyFiles=true`` improves git's performance on repositories with 1,000+ files.
-
-   ``--depth=2`` prunes the git history to reduce the size of the Spack installation.
-
 .. _shell-support:
 
 ^^^^^^^^^^^^^
@@ -255,10 +250,9 @@ Compiler configuration
 
 Spack has the ability to build packages with multiple compilers and
 compiler versions. Compilers can be made available to Spack by
-specifying them manually in ``compilers.yaml`` or ``packages.yaml``,
-or automatically by running ``spack compiler find``, but for
-convenience Spack will automatically detect compilers the first time
-it needs them.
+specifying them manually in ``compilers.yaml``, or automatically by
+running ``spack compiler find``, but for convenience Spack will
+automatically detect compilers the first time it needs them.
 
 .. _cmd-spack-compilers:
 
@@ -283,6 +277,10 @@ compilers`` or ``spack compiler list``:
        intel@14.0.1  intel@13.0.1  intel@12.1.2  intel@10.1
    -- clang -------------------------------------------------------
        clang@3.4  clang@3.3  clang@3.2  clang@3.1
+   -- pgi ---------------------------------------------------------
+       pgi@14.3-0   pgi@13.2-0  pgi@12.1-0   pgi@10.9-0  pgi@8.0-1
+       pgi@13.10-0  pgi@13.1-1  pgi@11.10-0  pgi@10.2-0  pgi@7.1-3
+       pgi@13.6-0   pgi@12.8-0  pgi@11.1-0   pgi@9.0-4   pgi@7.0-6
 
 Any of these compilers can be used to build Spack packages.  More on
 how this is done is in :ref:`sec-specs`.
@@ -459,54 +457,6 @@ specification. The operations available to modify the environment are ``set``, `
          prepend_path: # Similar for append|remove_path
            LD_LIBRARY_PATH: /ld/paths/added/by/setvars/sh
 
-.. note::
-
-   Spack is in the process of moving compilers from a separate
-   attribute to be handled like all other packages. As part of this
-   process, the ``compilers.yaml`` section will eventually be replaced
-   by configuration in the ``packages.yaml`` section. This new
-   configuration is now available, although it is not yet the default
-   behavior.
-
-Compilers can also be configured as external packages in the
-``packages.yaml`` config file. Any external package for a compiler
-(e.g. ``gcc`` or ``llvm``) will be treated as a configured compiler
-assuming the paths to the compiler executables are determinable from
-the prefix.
-
-If the paths to the compiler executable are not determinable from the
-prefix, you can add them to the ``extra_attributes`` field. Similarly,
-all other fields from the compilers config can be added to the
-``extra_attributes`` field for an external representing a compiler.
-
-Note that the format for the ``paths`` field in the
-``extra_attributes`` section is different than in the ``compilers``
-config. For compilers configured as external packages, the section is
-named ``compilers`` and the dictionary maps language names (``c``,
-``cxx``, ``fortran``) to paths, rather than using the names ``cc``,
-``fc``, and ``f77``.
-
-.. code-block:: yaml
-
-   packages:
-     gcc:
-       external:
-       - spec: gcc@12.2.0 arch=linux-rhel8-skylake
-         prefix: /usr
-         extra_attributes:
-           environment:
-             set:
-               GCC_ROOT: /usr
-       external:
-       - spec: llvm+clang@15.0.0 arch=linux-rhel8-skylake
-         prefix: /usr
-         extra_attributes:
-           compilers:
-             c: /usr/bin/clang-with-suffix
-             cxx: /usr/bin/clang++-with-extra-info
-             fortran: /usr/bin/gfortran
-           extra_rpaths:
-           - /usr/lib/llvm/
 
 ^^^^^^^^^^^^^^^^^^^^^^^
 Build Your Own Compiler
@@ -673,7 +623,7 @@ Fortran.
 
       compilers:
       - compiler:
-        # ...
+        ...
         paths:
           cc: /usr/bin/clang
           cxx: /usr/bin/clang++
@@ -802,6 +752,65 @@ flags to the ``icc`` command:
            spec: intel@15.0.24.4.9.3
 
 
+^^^
+PGI
+^^^
+
+PGI comes with two sets of compilers for C++ and Fortran,
+distinguishable by their names.  "Old" compilers:
+
+.. code-block:: yaml
+
+    cc:  /soft/pgi/15.10/linux86-64/15.10/bin/pgcc
+    cxx: /soft/pgi/15.10/linux86-64/15.10/bin/pgCC
+    f77: /soft/pgi/15.10/linux86-64/15.10/bin/pgf77
+    fc:  /soft/pgi/15.10/linux86-64/15.10/bin/pgf90
+
+"New" compilers:
+
+.. code-block:: yaml
+
+    cc:  /soft/pgi/15.10/linux86-64/15.10/bin/pgcc
+    cxx: /soft/pgi/15.10/linux86-64/15.10/bin/pgc++
+    f77: /soft/pgi/15.10/linux86-64/15.10/bin/pgfortran
+    fc:  /soft/pgi/15.10/linux86-64/15.10/bin/pgfortran
+
+Older installations of PGI contains just the old compilers; whereas
+newer installations contain the old and the new.  The new compiler is
+considered preferable, as some packages
+(``hdf``) will not build with the old compiler.
+
+When auto-detecting a PGI compiler, there are cases where Spack will
+find the old compilers, when you really want it to find the new
+compilers.  It is best to check this ``compilers.yaml``; and if the old
+compilers are being used, change ``pgf77`` and ``pgf90`` to
+``pgfortran``.
+
+Other issues:
+
+* There are reports that some packages will not build with PGI,
+  including ``libpciaccess`` and ``openssl``.  A workaround is to
+  build these packages with another compiler and then use them as
+  dependencies for PGI-build packages.  For example:
+
+  .. code-block:: console
+
+     $ spack install openmpi%pgi ^libpciaccess%gcc
+
+
+* PGI requires a license to use; see :ref:`licensed-compilers` for more
+  information on installation.
+
+.. note::
+
+   It is believed the problem with HDF 4 is that everything is
+   compiled with the ``F77`` compiler, but at some point some Fortran
+   90 code slipped in there. So compilers that can handle both FORTRAN
+   77 and Fortran 90 (``gfortran``, ``pgfortran``, etc) are fine.  But
+   compilers specific to one or the other (``pgf77``, ``pgf90``) won't
+   work.
+
+
 ^^^
 NAG
 ^^^
@@ -1306,6 +1315,187 @@ This will write the private key to the file `dinosaur.priv`.
     or for help on an issue or the Spack slack.
 
 
+.. _cray-support:
+
+-------------
+Spack on Cray
+-------------
+
+Spack differs slightly when used on a Cray system. The architecture spec
+can differentiate between the front-end and back-end processor and operating system.
+For example, on Edison at NERSC, the back-end target processor
+is "Ivy Bridge", so you can specify to use the back-end this way:
+
+.. code-block:: console
+
+   $ spack install zlib target=ivybridge
+
+You can also use the operating system to build against the back-end:
+
+.. code-block:: console
+
+   $ spack install zlib os=CNL10
+
+Notice that the name includes both the operating system name and the major
+version number concatenated together.
+
+Alternatively, if you want to build something for the front-end,
+you can specify the front-end target processor. The processor for a login node
+on Edison is "Sandy bridge" so we specify on the command line like so:
+
+.. code-block:: console
+
+   $ spack install zlib target=sandybridge
+
+And the front-end operating system is:
+
+.. code-block:: console
+
+   $ spack install zlib os=SuSE11
+
+^^^^^^^^^^^^^^^^^^^^^^^
+Cray compiler detection
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Spack can detect compilers using two methods. For the front-end, we treat
+everything the same. The difference lies in back-end compiler detection.
+Back-end compiler detection is made via the Tcl module avail command.
+Once it detects the compiler it writes the appropriate PrgEnv and compiler
+module name to compilers.yaml and sets the paths to each compiler with Cray\'s
+compiler wrapper names (i.e. cc, CC, ftn). During build time, Spack will load
+the correct PrgEnv and compiler module and will call appropriate wrapper.
+
+The compilers.yaml config file will also differ. There is a
+modules section that is filled with the compiler's Programming Environment
+and module name. On other systems, this field is empty []:
+
+.. code-block:: yaml
+
+   - compiler:
+       modules:
+         - PrgEnv-intel
+         - intel/15.0.109
+
+As mentioned earlier, the compiler paths will look different on a Cray system.
+Since most compilers are invoked using cc, CC and ftn, the paths for each
+compiler are replaced with their respective Cray compiler wrapper names:
+
+.. code-block:: yaml
+
+     paths:
+       cc: cc
+       cxx: CC
+       f77: ftn
+       fc: ftn
+
+As opposed to an explicit path to the compiler executable. This allows Spack
+to call the Cray compiler wrappers during build time.
+
+For more on compiler configuration, check out :ref:`compiler-config`.
+
+Spack sets the default Cray link type to dynamic, to better match other
+other platforms. Individual packages can enable static linking (which is the
+default outside of Spack on cray systems) using the ``-static`` flag.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Setting defaults and using Cray modules
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you want to use default compilers for each PrgEnv and also be able
+to load cray external modules, you will need to set up a ``packages.yaml``.
+
+Here's an example of an external configuration for cray modules:
+
+.. code-block:: yaml
+
+   packages:
+     mpich:
+       externals:
+       - spec: "mpich@7.3.1%gcc@5.2.0 arch=cray_xc-haswell-CNL10"
+         modules:
+         - cray-mpich
+       - spec: "mpich@7.3.1%intel@16.0.0.109 arch=cray_xc-haswell-CNL10"
+         modules:
+         - cray-mpich
+     all:
+       providers:
+         mpi: [mpich]
+
+This tells Spack that for whatever package that depends on mpi, load the
+cray-mpich module into the environment. You can then be able to use whatever
+environment variables, libraries, etc, that are brought into the environment
+via module load.
+
+.. note::
+
+    For Cray-provided packages, it is best to use ``modules:`` instead of ``prefix:``
+    in ``packages.yaml``, because the Cray Programming Environment heavily relies on
+    modules (e.g., loading the ``cray-mpich`` module adds MPI libraries to the
+    compiler wrapper link line).
+
+You can set the default compiler that Spack can use for each compiler type.
+If you want to use the Cray defaults, then set them under ``all:`` in packages.yaml.
+In the compiler field, set the compiler specs in your order of preference.
+Whenever you build with that compiler type, Spack will concretize to that version.
+
+Here is an example of a full packages.yaml used at NERSC
+
+.. code-block:: yaml
+
+   packages:
+     mpich:
+       externals:
+       - spec: "mpich@7.3.1%gcc@5.2.0 arch=cray_xc-CNL10-ivybridge"
+         modules:
+         - cray-mpich
+       - spec: "mpich@7.3.1%intel@16.0.0.109 arch=cray_xc-SuSE11-ivybridge"
+         modules:
+         - cray-mpich
+       buildable: False
+     netcdf:
+       externals:
+       - spec: "netcdf@4.3.3.1%gcc@5.2.0 arch=cray_xc-CNL10-ivybridge"
+         modules:
+         - cray-netcdf
+       - spec: "netcdf@4.3.3.1%intel@16.0.0.109 arch=cray_xc-CNL10-ivybridge"
+         modules:
+         - cray-netcdf
+       buildable: False
+     hdf5:
+       externals:
+       - spec: "hdf5@1.8.14%gcc@5.2.0 arch=cray_xc-CNL10-ivybridge"
+         modules:
+         - cray-hdf5
+       - spec: "hdf5@1.8.14%intel@16.0.0.109 arch=cray_xc-CNL10-ivybridge"
+         modules:
+         - cray-hdf5
+       buildable: False
+     all:
+       compiler: [gcc@5.2.0, intel@16.0.0.109]
+       providers:
+         mpi: [mpich]
+
+Here we tell spack that whenever we want to build with gcc use version 5.2.0 or
+if we want to build with intel compilers, use version 16.0.0.109. We add a spec
+for each compiler type for each cray modules. This ensures that for each
+compiler on our system we can use that external module.
+
+For more on external packages check out the section :ref:`sec-external-packages`.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Using Linux containers on Cray machines
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Spack uses environment variables particular to the Cray programming
+environment to determine which systems are Cray platforms. These
+environment variables may be propagated into containers that are not
+using the Cray programming environment.
+
+To ensure that Spack does not autodetect the Cray programming
+environment, unset the environment variable ``MODULEPATH``. This
+will cause Spack to treat a linux container on a Cray system as a base
+linux distro.
+
 .. _windows_support:
 
 ----------------
@@ -1326,7 +1516,6 @@ Required:
 * Microsoft Visual Studio
 * Python
 * Git
-* 7z
 
 Optional:
 * Intel Fortran (needed for some packages)
@@ -1340,8 +1529,6 @@ Microsoft Visual Studio
 """""""""""""""""""""""
 
 Microsoft Visual Studio provides the only Windows C/C++ compiler that is currently supported by Spack.
-Spack additionally requires that the Windows SDK (including WGL) to be installed as part of your
-visual studio installation as it is required to build many packages from source.
 
 We require several specific components to be included in the Visual Studio installation.
 One is the C/C++ toolset, which can be selected as "Desktop development with C++" or "C++ build tools,"
@@ -1349,7 +1536,6 @@ depending on installation type (Professional, Build Tools, etc.)  The other requ
 "C++ CMake tools for Windows," which can be selected from among the optional packages.
 This provides CMake and Ninja for use during Spack configuration.
 
-
 If you already have Visual Studio installed, you can make sure these components are installed by
 rerunning the installer.  Next to your installation, select "Modify" and look at the
 "Installation details" pane on the right.
@@ -1392,13 +1578,6 @@ as the project providing Git support on Windows. This is additionally the recomm
 for installing Git on Windows, a link to which can be found above. Spack requires the
 utilities vendored by this project.
 
-"""
-7zip
-"""
-
-A tool for extracting ``.xz`` files is required for extracting source tarballs. The latest 7zip
-can be located at https://sourceforge.net/projects/sevenzip/.
-
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Step 2: Install and setup Spack
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1425,14 +1604,16 @@ in a Windows CMD prompt.
 Step 3: Run and configure Spack
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-On Windows, Spack supports both primary native shells, Powershell and the traditional command prompt.
-To use Spack, pick your favorite shell, and run ``bin\spack_cmd.bat`` or ``share/spack/setup-env.ps1``
-(you may need to Run as Administrator) from the top-level spack
-directory. This will provide a Spack enabled shell. If you receive a warning message that Python is not in your ``PATH``
+To use Spack, run ``bin\spack_cmd.bat`` (you may need to Run as Administrator) from the top-level spack
+directory. This will provide a Windows command prompt with an environment properly set up with Spack
+and its prerequisites. If you receive a warning message that Python is not in your ``PATH``
 (which may happen if you installed Python from the website and not the Windows Store) add the location
 of the Python executable to your ``PATH`` now. You can permanently add Python to your ``PATH`` variable
 by using the ``Edit the system environment variables`` utility in Windows Control Panel.
 
+.. note::
+   Alternatively, Powershell can be used in place of CMD
+
 To configure Spack, first run the following command inside the Spack console:
 
 .. code-block:: console
@@ -1497,7 +1678,7 @@ and not tabs, so ensure that this is the case when editing one directly.
 
 .. note:: Cygwin
    The use of Cygwin is not officially supported by Spack and is not tested.
-   However Spack will not prevent this, so use if choosing to use Spack
+   However Spack will not throw an error, so use if choosing to use Spack
    with Cygwin, know that no functionality is garunteed.
 
 ^^^^^^^^^^^^^^^^^
@@ -1511,12 +1692,21 @@ Spack console via:
 
    spack install cpuinfo
 
-If in the previous step, you did not have CMake or Ninja installed, running the command above should install both packages
+If in the previous step, you did not have CMake or Ninja installed, running the command above should bootstrap both packages
 
-.. note:: Spec Syntax Caveats
-   Windows has a few idiosyncrasies when it comes to the Spack spec syntax and the use of certain shells
-   See the Spack spec syntax doc for more information
+"""""""""""""""""""""""""""
+Windows Compatible Packages
+"""""""""""""""""""""""""""
 
+Not all spack packages currently have Windows support. Some are inherently incompatible with the
+platform, and others simply have yet to be ported. To view the current set of packages with Windows
+support, the list command should be used via `spack list -t windows`. If there's a package you'd like
+to install on Windows but is not in that list, feel free to reach out to request the port or contribute
+the port yourself.
+
+.. note::
+   This is by no means a comprehensive list, some packages may have ports that were not tagged
+   while others may just work out of the box on Windows and have not been tagged as such.
 
 ^^^^^^^^^^^^^^
 For developers
@@ -1526,3 +1716,6 @@ The intent is to provide a Windows installer that will automatically set up
 Python, Git, and Spack, instead of requiring the user to do so manually.
 Instructions for creating the installer are at
 https://github.com/spack/spack/blob/develop/lib/spack/spack/cmd/installer/README.md
+
+Alternatively a pre-built copy of the Windows installer is available as an artifact of Spack's Windows CI
+available at each run of the CI on develop or any PR.

lib/spack/docs/index.rst

@@ -12,6 +12,10 @@
 Spack
 ===================
 
+.. epigraph::
+
+   `These are docs for the Spack package manager. For sphere packing, see` `pyspack <https://pyspack.readthedocs.io>`_.
+
 Spack is a package management tool designed to support multiple
 versions and configurations of software on a wide variety of platforms
 and environments.  It was designed for large supercomputing centers,
@@ -35,15 +39,10 @@ package:
 
 .. code-block:: console
 
-   $ git clone -c feature.manyFiles=true --depth=2 https://github.com/spack/spack.git
+   $ git clone -c feature.manyFiles=true https://github.com/spack/spack.git
    $ cd spack/bin
    $ ./spack install libelf
 
-.. note::
-   ``-c feature.manyFiles=true`` improves git's performance on repositories with 1,000+ files.
-
-   ``--depth=2`` prunes the git history to reduce the size of the Spack installation.
-
 If you're new to spack and want to start using it, see :doc:`getting_started`,
 or refer to the full manual below.
 

lib/spack/docs/module_file_support.rst

@@ -10,7 +10,7 @@ Modules (modules.yaml)
 ======================
 
 The use of module systems to manage user environment in a controlled way
-is a common practice at HPC centers that is sometimes embraced also by
+is a common practice at HPC centers that is often embraced also by
 individual programmers on their development machines. To support this
 common practice Spack integrates with `Environment Modules
 <http://modules.sourceforge.net/>`_ and `Lmod
@@ -21,38 +21,14 @@ Modules are one of several ways you can use Spack packages. For other
 options that may fit your use case better, you should also look at
 :ref:`spack load <spack-load>` and :ref:`environments <environments>`.
 
------------
-Quick start
------------
+----------------------------
+Using module files via Spack
+----------------------------
 
-In the current version of Spack, module files are not generated by default. To get started, you
-can generate module files for all currently installed packages by running either
-
-.. code-block:: console
-
-   $ spack module tcl refresh
-
-or
-
-.. code-block:: console
-
-   $ spack module lmod refresh
-
-Spack can also generate module files for all future installations automatically through the
-following configuration:
-
-.. code-block:: console
-
-   $ spack config add modules:default:enable:[tcl]
-
-or
-
-.. code-block:: console
-
-   $ spack config add modules:default:enable:[lmod]
-
-Assuming you have a module system installed, you should now be able to use the ``module`` command
-to interact with them:
+If you have installed a supported module system you should be able to
+run ``module avail`` to see what module
+files have been installed. Here is sample output of those programs,
+showing lots of installed packages:
 
 .. code-block:: console
 
@@ -89,17 +65,33 @@ scheme used at your site.
 Module file customization
 -------------------------
 
+Module files are generated by post-install hooks after the successful
+installation of a package.
+
+.. note::
+
+   Spack only generates modulefiles when a package is installed. If
+   you attempt to install a package and it is already installed, Spack
+   will not regenerate modulefiles for the package. This may lead to
+   inconsistent modulefiles if the Spack module configuration has
+   changed since the package was installed, either by editing a file
+   or changing scopes or environments.
+
+   Later in this section there is a subsection on :ref:`regenerating
+   modules <cmd-spack-module-refresh>` that will allow you to bring
+   your modules to a consistent state.
+
 The table below summarizes the essential information associated with
 the different file formats that can be generated by Spack:
 
 
-  +-----------+--------------+------------------------------+----------------------------------------------+----------------------+
-  |           | Hierarchical |  **Default root directory**  | **Default template file**                    | **Compatible tools** |
-  +===========+==============+==============================+==============================================+======================+
-  |  ``tcl``  | No           | share/spack/modules          | share/spack/templates/modules/modulefile.tcl | Env. Modules/Lmod    |
-  +-----------+--------------+------------------------------+----------------------------------------------+----------------------+
-  |  ``lmod`` | Yes          | share/spack/lmod             | share/spack/templates/modules/modulefile.lua | Lmod                 |
-  +-----------+--------------+------------------------------+----------------------------------------------+----------------------+
+  +-----------------------------+--------------------+-------------------------------+----------------------------------------------+----------------------+
+  |                             | **Hook name**      |  **Default root directory**   | **Default template file**                    | **Compatible tools** |
+  +=============================+====================+===============================+==============================================+======================+
+  |  **Tcl - Non-Hierarchical** | ``tcl``            |  share/spack/modules          | share/spack/templates/modules/modulefile.tcl | Env. Modules/Lmod    |
+  +-----------------------------+--------------------+-------------------------------+----------------------------------------------+----------------------+
+  |  **Lua - Hierarchical**     | ``lmod``           |  share/spack/lmod             | share/spack/templates/modules/modulefile.lua | Lmod                 |
+  +-----------------------------+--------------------+-------------------------------+----------------------------------------------+----------------------+
 
 
 Spack ships with sensible defaults for the generation of module files, but
@@ -110,7 +102,7 @@ In general you can override or extend the default behavior by:
  2. writing specific rules in the ``modules.yaml`` configuration file
  3. writing your own templates to override or extend the defaults
 
-The former method lets you express changes in the run-time environment
+The former method let you express changes in the run-time environment
 that are needed to use the installed software properly, e.g. injecting variables
 from language interpreters into their extensions. The latter two instead permit to
 fine tune the filesystem layout, content and creation of module files to meet
@@ -118,62 +110,79 @@ site specific conventions.
 
 .. _overide-api-calls-in-package-py:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setting environment variables dynamically in ``package.py``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Override API calls in ``package.py``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-There are two methods that you can implement in any ``package.py`` to dynamically affect the
-content of the module files generated by Spack. The most important one is
-``setup_run_environment``, which can be used to set environment variables in the module file that
-depend on the spec:
+There are two methods that you can override in any ``package.py`` to affect the
+content of the module files generated by Spack. The first one:
 
 .. code-block:: python
 
    def setup_run_environment(self, env):
-       if self.spec.satisfies("+foo"):
-           env.set("FOO", "bar")
+       pass
 
-The second, less commonly used, is ``setup_dependent_run_environment(self, env, dependent_spec)``,
-which allows a dependency to set variables in the module file of its dependents. This is typically
-used in packages like ``python``, ``r``, or ``perl`` to prepend the dependent's prefix to the
-search path of the interpreter (``PYTHONPATH``, ``R_LIBS``, ``PERL5LIB`` resp.), so it can locate
-the packages at runtime.
-
-For example, a simplified version of the ``python`` package could look like this:
+can alter the content of the module file associated with the same package where it is overridden.
+The second method:
 
 .. code-block:: python
 
    def setup_dependent_run_environment(self, env, dependent_spec):
-       if dependent_spec.package.extends(self.spec):
-           env.prepend_path("PYTHONPATH", dependent_spec.prefix.lib.python)
+       pass
 
-and would make any package that ``extends("python")`` have its library directory added to the
-``PYTHONPATH`` environment variable in the module file. It's much more convenient to set this
-variable here, than to repeat it in every Python extension's ``setup_run_environment`` method.
+can instead inject run-time environment modifications in the module files of packages
+that depend on it. In both cases you need to fill ``env`` with the desired
+list of environment modifications.
+
+.. admonition:: The ``r`` package and callback APIs
+
+  An example in which it is crucial to override both methods
+  is given by the ``r`` package. This package installs libraries and headers
+  in non-standard locations and it is possible to prepend the appropriate directory
+  to the corresponding environment variables:
+
+  ================== =================================
+   LD_LIBRARY_PATH    ``self.prefix/rlib/R/lib``
+   PKG_CONFIG_PATH    ``self.prefix/rlib/pkgconfig``
+  ================== =================================
+
+  with the following snippet:
+
+  .. literalinclude:: _spack_root/var/spack/repos/builtin/packages/r/package.py
+     :pyobject: R.setup_run_environment
+
+  The ``r`` package also knows which environment variable should be modified
+  to make language extensions provided by other packages available, and modifies
+  it appropriately in the override of the second method:
+
+  .. literalinclude:: _spack_root/var/spack/repos/builtin/packages/r/package.py
+     :pyobject: R.setup_dependent_run_environment
 
 .. _modules-yaml:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The ``modules.yaml`` config file and module sets
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+Write a configuration file
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The configuration files that control module generation behavior are named ``modules.yaml``. The
-default configuration looks like this:
+The configuration files that control module generation behavior
+are named ``modules.yaml``. The default configuration:
 
 .. literalinclude:: _spack_root/etc/spack/defaults/modules.yaml
    :language: yaml
 
-You can define one or more **module sets**, each of which can be configured separately with regard
-to install location, naming scheme, inclusion and exclusion, autoloading, et cetera.
+activates the hooks to generate ``tcl`` module files and inspects
+the installation folder of each package for the presence of a set of subdirectories
+(``bin``, ``man``, ``share/man``, etc.). If any is found its full path is prepended
+to the environment variables listed below the folder name.
 
-The default module set is aptly named ``default``. All
-:ref:`Spack commands that operate on modules <maintaining-module-files>` apply to the ``default``
-module set, unless another module set is specified explicitly (with the ``--name`` flag).
+Spack modules can be configured for multiple module sets. The default
+module set is named ``default``. All Spack commands which operate on
+modules default to apply the ``default`` module set, but can be
+applied to any module set in the configuration.
 
-
-^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""
 Changing the modules root
-^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""
 
 As shown in the table above, the default module root for ``lmod`` is
 ``$spack/share/spack/lmod`` and the default root for ``tcl`` is
@@ -189,7 +198,7 @@ set by changing the ``roots`` key of the configuration.
      my_custom_lmod_modules:
        roots:
          lmod: /path/to/install/custom/lmod/modules
-         # ...
+         ...
 
 This configuration will create two module sets. The default module set
 will install its ``tcl`` modules to ``/path/to/install/tcl/modules``
@@ -215,32 +224,25 @@ location could be confusing to users of your modules. In the next
 section, we will discuss enabling and disabling module types (module
 file generators) for each module set.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Automatically generating module files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""
+Activate other hooks
+""""""""""""""""""""
 
-Spack can be configured to automatically generate module files as part of package installation.
-This is done by adding the desired module systems to the ``enable`` list.
+Any other module file generator shipped with Spack can be activated adding it to the
+list under the ``enable`` key in the module file. Currently the only generator that
+is not active by default is ``lmod``, which produces hierarchical lua module files.
+
+Each module system can then be configured separately. In fact, you should list configuration
+options that affect a particular type of module files under a top level key corresponding
+to the generator being customized:
 
 .. code-block:: yaml
 
    modules:
      default:
        enable:
-       - tcl
-       - lmod
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Configuring ``tcl`` and ``lmod`` modules
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can configure the behavior of either module system separately, under a key corresponding to
-the generator being customized:
-
-.. code-block:: yaml
-
-   modules:
-     default:
+         - tcl
+         - lmod
        tcl:
          # contains environment modules specific customizations
        lmod:
@@ -251,82 +253,16 @@ either change the layout of the module files on the filesystem, or they will aff
 their content. For the latter point it is possible to use anonymous specs
 to fine tune the set of packages on which the modifications should be applied.
 
-.. _autoloading-dependencies:
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Autoloading and hiding dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A module file should set the variables that are needed for an application to work. But since an
-application often has many dependencies, where should all the environment variables for those be
-set? In Spack the rule is that each package sets the runtime variables that are needed by the
-package itself, and no more. This way, dependencies can be loaded standalone too, and duplication
-of environment variables is avoided.
-
-That means however that if you want to use an application, you need to load the modules for all its
-dependencies. Of course this is not something you would want users to do manually.
-
-Since Spack knows the dependency graph of every package, it can easily generate module files that
-automatically load the modules for its dependencies recursively. It is enabled by default for both
-Lmod and Environment Modules under the ``autoload: direct`` config option. The former system has
-builtin support through the ``depends_on`` function, the latter simply uses a ``module load``
-statement. Both module systems (at least in newer versions) do reference counting, so that if a
-module is loaded by two different modules, it will only be unloaded after the others are.
-
-The ``autoload`` key accepts the values:
-
-  * ``none``: no autoloading
-  * ``run``: autoload direct *run* type dependencies
-  * ``direct``: autoload direct *link and run* type dependencies
-  * ``all``: autoload all dependencies
-
-In case of ``run`` and ``direct``, a ``module load`` triggers a recursive load.
-
-The ``direct`` option is most correct: there are cases where pure link dependencies need to set
-variables for themselves, or need to have variables of their own dependencies set.
-
-In practice however, ``run`` is often sufficient, and may make ``module load`` snappier.
-
-The ``all`` option is discouraged and seldomly used.
-
-A common complaint about autoloading is the large number of modules that are visible to the user.
-Spack has a solution for this as well: ``hide_implicits: true``. This ensures that only those
-packages you've explicitly installed are exposed by ``module avail``, but still allows for
-autoloading of hidden dependencies. Lmod should support hiding implicits in general, while
-Environment Modules requires version 4.7 or higher.
-
-.. note::
-   If supported by your module system, we highly encourage the following configuration that enables
-   autoloading and hiding of implicits. It ensures all runtime variables are set correctly,
-   including those for dependencies, without overwhelming the user with a large number of available
-   modules. Further, it makes it easier to get readable module names without collisions, see the
-   section below on :ref:`modules-projections`.
-
-    .. code-block:: yaml
-  
-        modules:
-          default:
-            tcl:
-              hide_implicits: true
-              all:
-                autoload: direct # or `run`
-            lmod:
-              hide_implicits: true
-              all:
-                autoload: direct # or `run`
-
 .. _anonymous_specs:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setting environment variables for selected packages in config
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""
+Selection by anonymous specs
+""""""""""""""""""""""""""""
 
-In the configuration file you can filter particular specs, and make further changes to the
-environment variables that go into their module files. This is very powerful when you want to avoid
-:ref:`modifying the package itself <overide-api-calls-in-package-py>`, or when you want to set
-certain variables on multiple selected packages at once.
-
-For instance, in the snippet below:
+In the configuration file you can use *anonymous specs* (i.e. specs
+that **are not required to have a root package** and are thus used just
+to express constraints) to apply certain modifications on a selected set
+of the installed software. For instance, in the snippet below:
 
 .. code-block:: yaml
 
@@ -369,28 +305,12 @@ the variable ``FOOBAR`` will be unset.
 .. note::
    Order does matter
      The modifications associated with the ``all`` keyword are always evaluated
-     first, no matter where they appear in the configuration file. All the other changes to
-     environment variables for matching specs are evaluated from top to bottom.
+     first, no matter where they appear in the configuration file. All the other
+     spec constraints are instead evaluated top to bottom.
 
-.. warning::
-
-     As general advice, it's often better to set as few unnecessary variables as possible. For
-     example, the following seemingly innocent and potentially useful configuration
-
-     .. code-block:: yaml
-
-        all:
-          environment:
-            set:
-              "{name}_ROOT": "{prefix}"
-
-     sets ``BINUTILS_ROOT`` to its prefix in modules for ``binutils``, which happens to break
-     the ``gcc`` compiler: it uses this variable as its default search path for certain object
-     files and libraries, and by merely setting it, everything fails to link.
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""""""""""""""""""
 Exclude or include specific module files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""""""""""""""""""
 
 You can use anonymous specs also to prevent module files from being written or
 to force them to be written. Consider the case where you want to hide from users
@@ -410,19 +330,14 @@ you will prevent the generation of module files for any package that
 is compiled with ``gcc@4.4.7``, with the only exception of any ``gcc``
 or any ``llvm`` installation.
 
-It is safe to combine ``exclude`` and ``autoload``
-:ref:`mentioned above <autoloading-dependencies>`. When ``exclude`` prevents a module file to be
-generated for a dependency, the ``autoload`` feature will simply not generate a statement to load
-it.
-
 
 .. _modules-projections:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""""""""
 Customize the naming of modules
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""""""""
 
-The names of environment modules generated by Spack are not always easy to
+The names of environment modules generated by spack are not always easy to
 fully comprehend due to the long hash in the name. There are three module
 configuration options to help with that. The first is a global setting to
 adjust the hash length. It can be set anywhere from 0 to 32 and has a default
@@ -438,13 +353,6 @@ shows how to set hash length in the module file names:
        tcl:
          hash_length: 7
 
-.. tip::
-
-   Using ``hide_implicits: true`` (see :ref:`autoloading-dependencies`) vastly reduces the number
-   modules exposed to the user. The hidden modules always contain the hash in their name, and are
-   not influenced by the ``hash_length`` setting. Hidden implicits thus make it easier to use a
-   short hash length or no hash at all, without risking name conflicts.
-
 To help make module names more readable, and to help alleviate name conflicts
 with a short hash, one can use the ``suffixes`` option in the modules
 configuration file. This option will add strings to modules that match a spec.
@@ -457,12 +365,12 @@ For instance, the following config options,
        tcl:
          all:
            suffixes:
-             ^python@3: 'python{^python.version}'
+             ^python@2.7.12: 'python-2.7.12'
              ^openblas: 'openblas'
 
-will add a ``python-3.12.1`` version string to any packages compiled with
-Python matching the spec, ``python@3``. This is useful to know which
-version of Python a set of Python extensions is associated with. Likewise, the
+will add a ``python-2.7.12`` version string to any packages compiled with
+python matching the spec, ``python@2.7.12``. This is useful to know which
+version of python a set of python extensions is associated with. Likewise, the
 ``openblas`` string is attached to any program that has openblas in the spec,
 most likely via the ``+blas`` variant specification.
 
@@ -560,11 +468,41 @@ that are already in the Lmod hierarchy.
    For hierarchies that are deeper than three layers ``lmod spider`` may have some issues.
    See `this discussion on the Lmod project <https://github.com/TACC/Lmod/issues/114>`_.
 
+""""""""""""""""""""""
+Select default modules
+""""""""""""""""""""""
+
+By default, when multiple modules of the same name share a directory,
+the highest version number will be the default module. This behavior
+of the ``module`` command can be overridden with a symlink named
+``default`` to the desired default module. If you wish to configure
+default modules with Spack, add a ``defaults`` key to your modules
+configuration:
+
+.. code-block:: yaml
+
+  modules:
+    my-module-set:
+      tcl:
+        defaults:
+        - gcc@10.2.1
+        - hdf5@1.2.10+mpi+hl%gcc
+
+These defaults may be arbitrarily specific. For any package that
+satisfies a default, Spack will generate the module file in the
+appropriate path, and will generate a default symlink to the module
+file as well.
+
+.. warning::
+  If Spack is configured to generate multiple default packages in the
+  same directory, the last modulefile to be generated will be the
+  default module.
+
 .. _customize-env-modifications:
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""""""""""""
 Customize environment modifications
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""""""""""""""""""
 
 You can control which prefixes in a Spack package are added to
 environment variables with the ``prefix_inspections`` section; this
@@ -662,9 +600,9 @@ stack to users who are likely to inspect the modules to find full
 paths to software, when it is desirable to present the users with a
 simpler set of paths than those generated by the Spack install tree.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""""""""""
 Filter out environment modifications
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""""""""""
 
 Modifications to certain environment variables in module files are there by
 default, for instance because they are generated by prefix inspections.
@@ -684,37 +622,49 @@ do so by using the ``exclude_env_vars``:
 The configuration above will generate module files that will not contain
 modifications to either ``CPATH`` or ``LIBRARY_PATH``.
 
-^^^^^^^^^^^^^^^^^^^^^^
-Select default modules
-^^^^^^^^^^^^^^^^^^^^^^
 
-By default, when multiple modules of the same name share a directory,
-the highest version number will be the default module. This behavior
-of the ``module`` command can be overridden with a symlink named
-``default`` to the desired default module. If you wish to configure
-default modules with Spack, add a ``defaults`` key to your modules
-configuration:
+.. _autoloading-dependencies:
+
+"""""""""""""""""""""
+Autoload dependencies
+"""""""""""""""""""""
+
+Often it is required for a module to have its (transient) dependencies loaded as well.
+One example where this is useful is when one package needs to use executables provided
+by its dependency; when the dependency is autoloaded, the executable will be in the
+PATH. Similarly for scripting languages such as Python, packages and their dependencies
+have to be loaded together.
+
+Autoloading is enabled by default for Lmod and Environment Modules. The former
+has builtin support for through the ``depends_on`` function. The latter uses
+``module load`` statement to load and track dependencies.
+
+Autoloading can also be enabled conditionally:
 
 .. code-block:: yaml
 
-  modules:
-    my-module-set:
-      tcl:
-        defaults:
-        - gcc@10.2.1
-        - hdf5@1.2.10+mpi+hl%gcc
+    modules:
+      default:
+        tcl:
+          all:
+            autoload: none
+          ^python:
+            autoload: direct
 
-These defaults may be arbitrarily specific. For any package that
-satisfies a default, Spack will generate the module file in the
-appropriate path, and will generate a default symlink to the module
-file as well.
+The configuration file above will produce module files that will
+load their direct dependencies if the package installed depends on ``python``.
+The allowed values for the ``autoload`` statement are either ``none``,
+``direct`` or ``all``.
 
-.. warning::
-  If Spack is configured to generate multiple default packages in the
-  same directory, the last modulefile to be generated will be the
-  default module.
-
-.. _maintaining-module-files:
+.. note::
+  Tcl prerequisites
+     In the ``tcl`` section of the configuration file it is possible to use
+     the ``prerequisites`` directive that accepts the same values as
+     ``autoload``. It will produce module files that have a ``prereq``
+     statement, which autoloads dependencies on Environment Modules when its
+     ``auto_handling`` configuration option is enabled. If Environment Modules
+     is installed with Spack, ``auto_handling`` is enabled by default starting
+     version 4.2. Otherwise it is enabled by default since version 5.0.
 
 ------------------------
 Maintaining Module Files

lib/spack/docs/packages_yaml.rst

@@ -487,56 +487,6 @@ present. For instance with a configuration like:
 
 you will use ``mvapich2~cuda %gcc`` as an ``mpi`` provider.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Conflicts and strong preferences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If the semantic of requirements is too strong, you can also express "strong preferences" and "conflicts"
-from configuration files:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       prefer:
-       - '%clang'
-       conflict:
-       - '+shared'
-
-The ``prefer`` and ``conflict`` sections can be used whenever a ``require`` section is allowed.
-The argument is always a list of constraints, and each constraint can be either a simple string,
-or a more complex object:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       conflict:
-       - spec: '%clang'
-         when: 'target=x86_64_v3'
-         message: 'reason why clang cannot be used'
-
-The ``spec`` attribute is mandatory, while both ``when`` and ``message`` are optional.
-
-.. note::
-
-   Requirements allow for expressing both "strong preferences" and "conflicts".
-   The syntax for doing so, though, may not be immediately clear. For
-   instance, if we want to prevent any package from using ``%clang``, we can set:
-
-   .. code-block:: yaml
-
-      packages:
-        all:
-          require:
-          - one_of: ['%clang', '@:']
-
-   Since only one of the requirements must hold, and ``@:`` is always true, the rule above is
-   equivalent to a conflict. For "strong preferences" we need to substitute the ``one_of`` policy
-   with ``any_of``.
-
-
-
 .. _package-preferences:
 
 -------------------
@@ -647,8 +597,6 @@ manually placed files within the install prefix are owned by the
 assigned group. If no group is assigned, Spack will allow the OS
 default behavior to go as expected.
 
-.. _assigning-package-attributes:
-
 ----------------------------
 Assigning Package Attributes
 ----------------------------
@@ -659,11 +607,10 @@ You can assign class-level attributes in the configuration:
 
   packages:
     mpileaks:
-      package_attributes:
-        # Override existing attributes
-        url: http://www.somewhereelse.com/mpileaks-1.0.tar.gz
-        # ... or add new ones
-        x: 1
+      # Override existing attributes
+      url: http://www.somewhereelse.com/mpileaks-1.0.tar.gz
+      # ... or add new ones
+      x: 1
 
 Attributes set this way will be accessible to any method executed
 in the package.py file (e.g. the ``install()`` method). Values for these

lib/spack/docs/pipelines.rst

@@ -59,7 +59,7 @@ Functional Example
 ------------------
 
 The simplest fully functional standalone example of a working pipeline can be
-examined live at this example `project <https://gitlab.com/spack/pipeline-quickstart>`_
+examined live at this example `project <https://gitlab.com/scott.wittenburg/spack-pipeline-demo>`_
 on gitlab.com.
 
 Here's the ``.gitlab-ci.yml`` file from that example that builds and runs the
@@ -67,46 +67,39 @@ pipeline:
 
 .. code-block:: yaml
 
-   stages: [ "generate", "build" ]
+   stages: [generate, build]
 
    variables:
-     SPACK_REPOSITORY: "https://github.com/spack/spack.git"
-     SPACK_REF: "develop-2024-10-06"
-     SPACK_USER_CONFIG_PATH: ${CI_PROJECT_DIR}
-     SPACK_BACKTRACE: 1
+     SPACK_REPO: https://github.com/scottwittenburg/spack.git
+     SPACK_REF: pipelines-reproducible-builds
 
    generate-pipeline:
-     tags:
-       - saas-linux-small-amd64
      stage: generate
+     tags:
+       - docker
      image:
-       name: ghcr.io/spack/ubuntu20.04-runner-x86_64:2023-01-01
-     script:
-       - git clone ${SPACK_REPOSITORY}
-       - cd spack && git checkout ${SPACK_REF} && cd ../
+       name: ghcr.io/scottwittenburg/ecpe4s-ubuntu18.04-runner-x86_64:2020-09-01
+       entrypoint: [""]
+     before_script:
+       - git clone ${SPACK_REPO}
+       - pushd spack && git checkout ${SPACK_REF} && popd
        - . "./spack/share/spack/setup-env.sh"
-       - spack --version
+     script:
        - spack env activate --without-view .
-       - spack -d -v --color=always
-         ci generate
-         --check-index-only
+       - spack -d ci generate
          --artifacts-root "${CI_PROJECT_DIR}/jobs_scratch_dir"
-         --output-file "${CI_PROJECT_DIR}/jobs_scratch_dir/cloud-ci-pipeline.yml"
+         --output-file "${CI_PROJECT_DIR}/jobs_scratch_dir/pipeline.yml"
      artifacts:
        paths:
          - "${CI_PROJECT_DIR}/jobs_scratch_dir"
 
-   build-pipeline:
+   build-jobs:
      stage: build
      trigger:
        include:
-         - artifact: jobs_scratch_dir/cloud-ci-pipeline.yml
+         - artifact: "jobs_scratch_dir/pipeline.yml"
            job: generate-pipeline
        strategy: depend
-     needs:
-       - artifacts: True
-         job: generate-pipeline
-
 
 The key thing to note above is that there are two jobs: The first job to run,
 ``generate-pipeline``, runs the ``spack ci generate`` command to generate a
@@ -121,93 +114,82 @@ And here's the spack environment built by the pipeline represented as a
    spack:
      view: false
      concretizer:
-       unify: true
-       reuse: false
+       unify: false
 
      definitions:
      - pkgs:
        - zlib
-       - bzip2 ~debug
-     - compiler:
-       - '%gcc'
+       - bzip2
+     - arch:
+       - '%gcc@7.5.0 arch=linux-ubuntu18.04-x86_64'
 
      specs:
      - matrix:
        - - $pkgs
-       - - $compiler
+       - - $arch
+
+     mirrors: { "mirror": "s3://spack-public/mirror" }
 
      ci:
-       target: gitlab
-
+       enable-artifacts-buildcache: True
+       rebuild-index: False
        pipeline-gen:
        - any-job:
-           tags:
-             - saas-linux-small-amd64
-           image:
-             name: ghcr.io/spack/ubuntu20.04-runner-x86_64:2023-01-01
            before_script:
-           - git clone ${SPACK_REPOSITORY}
-           - cd spack && git checkout ${SPACK_REF} && cd ../
-           - . "./spack/share/spack/setup-env.sh"
-           - spack --version
-           - export SPACK_USER_CONFIG_PATH=${CI_PROJECT_DIR}
-           - spack config blame mirrors
+             - git clone ${SPACK_REPO}
+             - pushd spack && git checkout ${SPACK_CHECKOUT_VERSION} && popd
+             - . "./spack/share/spack/setup-env.sh"
+       - build-job:
+           tags: [docker]
+           image:
+             name: ghcr.io/scottwittenburg/ecpe4s-ubuntu18.04-runner-x86_64:2020-09-01
+             entrypoint: [""]
 
 
+The elements of this file important to spack ci pipelines are described in more
+detail below, but there are a couple of things to note about the above working
+example:
+
 .. note::
-   The use of ``reuse: false`` in spack environments used for pipelines is
-   almost always what you want, as without it your pipelines will not rebuild
-   packages even if package hashes have changed. This is due to the concretizer
-   strongly preferring known hashes when ``reuse: true``.
+   There is no ``script`` attribute specified for here. The reason for this is
+   Spack CI will automatically generate reasonable default scripts. More
+   detail on what is in these scripts can be found below.
 
-The ``ci`` section in the above environment file contains the bare minimum
-configuration required for ``spack ci generate`` to create a working pipeline.
-The ``target: gitlab`` tells spack that the desired pipeline output is for
-gitlab.  However, this isn't strictly required, as currently gitlab is the
-only possible output format for pipelines. The ``pipeline-gen`` section
-contains the key information needed to specify attributes for the generated
-jobs.  Notice that it contains a list which has only a single element in
-this case.  In real pipelines it will almost certainly have more elements,
-and in those cases, order is important: spack starts at the bottom of the
-list and works upwards when applying attributes.
+   Also notice the ``before_script`` section. It is required when using any of the
+   default scripts to source the ``setup-env.sh`` script in order to inform
+   the default scripts where to find the ``spack`` executable.
 
-But in this simple case, we use only the special key ``any-job`` to
-indicate that spack should apply the specified attributes (``tags``, ``image``,
-and ``before_script``) to any job it generates.  This includes jobs for
-building/pushing all packages, a ``rebuild-index`` job at the end of the
-pipeline, as well as any ``noop`` jobs that might be needed by gitlab when
-no rebuilds are required.
+Normally ``enable-artifacts-buildcache`` is not recommended in production as it
+results in large binary artifacts getting transferred back and forth between
+gitlab and the runners.  But in this example on gitlab.com where there is no
+shared, persistent file system, and where no secrets are stored for giving
+permission to write to an S3 bucket, ``enabled-buildcache-artifacts`` is the only
+way to propagate binaries from jobs to their dependents.
 
-Something to note is that in this simple case, we rely on spack to
-generate a reasonable script for the package build jobs (it just creates
-a script that invokes ``spack ci rebuild``).
+Also, it is usually a good idea to let the pipeline generate a final "rebuild the
+buildcache index" job, so that subsequent pipeline generation can quickly determine
+which specs are up to date and which need to be rebuilt (it's a good idea for other
+reasons as well, but those are out of scope for this discussion).  In this case we
+have disabled it (using ``rebuild-index: False``) because the index would only be
+generated in the artifacts mirror anyway, and consequently would not be available
+during subsequent pipeline runs.
 
-Another thing to note is the use of the ``SPACK_USER_CONFIG_DIR`` environment
-variable in any generated jobs.  The purpose of this is to make spack
-aware of one final file in the example, the one that contains the mirror
-configuration.  This file, ``mirrors.yaml`` looks like this:
+.. note::
+   With the addition of reproducible builds (#22887) a previously working
+   pipeline will require some changes:
 
-.. code-block:: yaml
+   * In the build-jobs, the environment location changed.
+     This will typically show as a ``KeyError`` in the failing job. Be sure to
+     point to ``${SPACK_CONCRETE_ENV_DIR}``.
 
-   mirrors:
-     buildcache-destination:
-       url: oci://registry.gitlab.com/spack/pipeline-quickstart
-       binary: true
-       access_pair:
-         id_variable: CI_REGISTRY_USER
-         secret_variable: CI_REGISTRY_PASSWORD
+   * When using ``include`` in your environment, be sure to make the included
+     files available in the build jobs. This means adding those files to the
+     artifact directory. Those files will also be missing in the reproducibility
+     artifact.
 
-
-Note the name of the mirror is ``buildcache-destination``, which is required
-as of Spack 0.23 (see below for more information).  The mirror url simply
-points to the container registry associated with the project, while
-``id_variable`` and ``secret_variable`` refer to to environment variables
-containing the access credentials for the mirror.
-
-When spack builds packages for this example project, they will be pushed to
-the project container registry, where they will be available for subsequent
-jobs to install as dependencies, or for other pipelines to use to build runnable
-container images.
+   * Because the location of the environment changed, including files with
+     relative path may have to be adapted to work both in the project context
+     (generation job) and in the concrete env dir context (build job).
 
 -----------------------------------
 Spack commands supporting pipelines
@@ -271,6 +253,17 @@ can easily happen if it is not updated frequently, this behavior ensures that
 spack has a way to know for certain about the status of any concrete spec on
 the remote mirror, but can slow down pipeline generation significantly.
 
+The ``--optimize`` argument is experimental and runs the generated pipeline
+document through a series of optimization passes designed to reduce the size
+of the generated file.
+
+The ``--dependencies`` is also experimental and disables what in Gitlab is
+referred to as DAG scheduling, internally using the ``dependencies`` keyword
+rather than ``needs`` to list dependency jobs.  The drawback of using this option
+is that before any job can begin, all jobs in previous stages must first
+complete.  The benefit is that Gitlab allows more dependencies to be listed
+when using ``dependencies`` instead of ``needs``.
+
 The optional ``--output-file`` argument should be an absolute path (including
 file name) to the generated pipeline, and if not given, the default is
 ``./.gitlab-ci.yml``.
@@ -435,6 +428,15 @@ configuration with a ``script`` attribute. Specifying a signing job without a sc
 does not create a signing job and the job configuration attributes will be ignored.
 Signing jobs are always assigned the runner tags ``aws``, ``protected``, and ``notary``.
 
+^^^^^^^^^^^^^^^^^
+Cleanup (cleanup)
+^^^^^^^^^^^^^^^^^
+
+When using ``temporary-storage-url-prefix`` the cleanup job will destroy the mirror
+created for the associated Gitlab pipeline. Cleanup jobs do not allow modifying the
+script, but do expect that the spack command is in the path and require a
+``before_script`` to be specified that sources the ``setup-env.sh`` script.
+
 .. _noop_jobs:
 
 ^^^^^^^^^^^^
@@ -601,77 +603,6 @@ the attributes will be merged starting from the bottom match going up to the top
 
 In the case that no match is found in a submapping section, no additional attributes will be applied.
 
-
-^^^^^^^^^^^^^^^^^^^^^^^^
-Dynamic Mapping Sections
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-For large scale CI where cost optimization is required, dynamic mapping allows for the use of real-time
-mapping schemes served by a web service. This type of mapping does not support the ``-remove`` type
-behavior, but it does follow the rest of the merge rules for configurations.
-
-The dynamic mapping service needs to implement a single REST API interface for getting
-requests ``GET <URL>[:PORT][/PATH]?spec=<pkg_name@pkg_version +variant1+variant2%compiler@compiler_version>``.
-
-example request.
-
-.. code-block::
-
-  https://my-dyn-mapping.spack.io/allocation?spec=zlib-ng@2.1.6 +compat+opt+shared+pic+new_strategies arch=linux-ubuntu20.04-x86_64_v3%gcc@12.0.0
-
-
-With an example response the updates kubernetes request variables, overrides the max retries for gitlab,
-and prepends a note about the modifications made by the my-dyn-mapping.spack.io service.
-
-.. code-block::
-
-  200 OK
-
-  {
-    "variables":
-    {
-      "KUBERNETES_CPU_REQUEST": "500m",
-      "KUBERNETES_MEMORY_REQUEST": "2G",
-    },
-    "retry": { "max:": "1"}
-    "script+:":
-    [
-      "echo \"Job modified by my-dyn-mapping.spack.io\""
-    ]
-  }
-
-
-The ci.yaml configuration section takes the URL endpoint as well as a number of options to configure how responses are handled.
-
-It is possible to specify a list of allowed and ignored configuration attributes under ``allow`` and ``ignore``
-respectively. It is also possible to configure required attributes under ``required`` section.
-
-Options to configure the client timeout and SSL verification using the ``timeout`` and ``verify_ssl`` options.
-By default, the ``timeout`` is set to the option in ``config:timeout`` and ``veryify_ssl`` is set the the option in ``config::verify_ssl``.
-
-Passing header parameters to the request can be achieved through the ``header`` section. The values of the variables passed to the
-header may be environment variables that are expanded at runtime, such as a private token configured on the runner.
-
-Here is an example configuration pointing to ``my-dyn-mapping.spack.io/allocation``.
-
-
-.. code-block:: yaml
-
-  ci:
-  - dynamic-mapping:
-      endpoint: my-dyn-mapping.spack.io/allocation
-      timeout: 10
-      verify_ssl: True
-      header:
-        PRIVATE_TOKEN: ${MY_PRIVATE_TOKEN}
-        MY_CONFIG: "fuzz_allocation:false"
-      allow:
-      - variables
-      ignore:
-      - script
-      require: []
-
-
 ^^^^^^^^^^^^^
 Bootstrapping
 ^^^^^^^^^^^^^
@@ -743,13 +674,26 @@ build the package.
 
 When including a bootstrapping phase as in the example above, the result is that
 the bootstrapped compiler packages will be pushed to the binary mirror (and the
-local artifacts mirror) before the actual release specs are built.
+local artifacts mirror) before the actual release specs are built. In this case,
+the jobs corresponding to subsequent release specs are configured to
+``install_missing_compilers``, so that if spack is asked to install a package
+with a compiler it doesn't know about, it can be quickly installed from the
+binary mirror first.
 
 Since bootstrapping compilers is optional, those items can be left out of the
 environment/stack file, and in that case no bootstrapping will be done (only the
 specs will be staged for building) and the runners will be expected to already
 have all needed compilers installed and configured for spack to use.
 
+^^^^^^^^^^^^^^^^^^^
+Pipeline Buildcache
+^^^^^^^^^^^^^^^^^^^
+
+The ``enable-artifacts-buildcache`` key
+takes a boolean and determines whether the pipeline uses artifacts to store and
+pass along the buildcaches from one stage to the next (the default if you don't
+provide this option is ``False``).
+
 ^^^^^^^^^^^^^^^^
 Broken Specs URL
 ^^^^^^^^^^^^^^^^
@@ -866,7 +810,7 @@ generated by ``spack ci generate``.  You also want your generated rebuild jobs
 .. code-block:: yaml
 
    spack:
-     # ...
+     ...
      ci:
        pipeline-gen:
        - build-job:

lib/spack/docs/repositories.rst

@@ -17,7 +17,7 @@ experimental software separately from the built-in repository. Spack
 allows you to configure local repositories using either the
 ``repos.yaml`` or the ``spack repo`` command.
 
-A package repository is a directory structured like this::
+A package repository a directory structured like this::
 
   repo/
       repo.yaml
@@ -476,3 +476,9 @@ implemented using Python's built-in `sys.path
 :py:mod:`spack.repo` module implements a custom `Python importer
 <https://docs.python.org/2/library/imp.html>`_.
 
+.. warning::
+
+   The mechanism for extending packages is not yet extensively tested,
+   and extending packages across repositories imposes inter-repo
+   dependencies, which may be hard to manage.  Use this feature at your
+   own risk, but let us know if you have a use case for it.

lib/spack/docs/requirements.txt

@@ -1,13 +1,13 @@
-sphinx==8.1.3
+sphinx==7.2.6
 sphinxcontrib-programoutput==0.17
-sphinx_design==0.6.1
-sphinx-rtd-theme==3.0.2
-python-levenshtein==0.26.1
-docutils==0.21.2
-pygments==2.18.0
-urllib3==2.2.3
-pytest==8.3.4
+sphinx_design==0.5.0
+sphinx-rtd-theme==2.0.0
+python-levenshtein==0.23.0
+docutils==0.20.1
+pygments==2.17.2
+urllib3==2.1.0
+pytest==7.4.4
 isort==5.13.2
-black==24.10.0
-flake8==7.1.1
-mypy==1.11.1
+black==23.12.1
+flake8==7.0.0
+mypy==1.8.0

lib/spack/env/cc

@@ -47,8 +47,7 @@ SPACK_F77_RPATH_ARG
 SPACK_FC_RPATH_ARG
 SPACK_LINKER_ARG
 SPACK_SHORT_SPEC
-SPACK_SYSTEM_DIRS
-SPACK_MANAGED_DIRS"
+SPACK_SYSTEM_DIRS"
 
 # Optional parameters that aren't required to be set
 
@@ -101,9 +100,10 @@ setsep() {
     esac
 }
 
-# prepend LISTNAME ELEMENT
+# prepend LISTNAME ELEMENT [SEP]
 #
-# Prepend ELEMENT to the list stored in the variable LISTNAME.
+# Prepend ELEMENT to the list stored in the variable LISTNAME,
+# assuming the list is separated by SEP.
 # Handles empty lists and single-element lists.
 prepend() {
     varname="$1"
@@ -173,44 +173,20 @@ preextend() {
     unset IFS
 }
 
-execute() {
-    # dump the full command if the caller supplies SPACK_TEST_COMMAND=dump-args
-    if [ -n "${SPACK_TEST_COMMAND=}" ]; then
-        case "$SPACK_TEST_COMMAND" in
-            dump-args)
-                IFS="$lsep"
-                for arg in $full_command_list; do
-                    echo "$arg"
-                done
-                unset IFS
-                exit
-                ;;
-            dump-env-*)
-                var=${SPACK_TEST_COMMAND#dump-env-}
-                eval "printf '%s\n' \"\$0: \$var: \$$var\""
-                ;;
-            *)
-                die "Unknown test command: '$SPACK_TEST_COMMAND'"
-                ;;
-        esac
-    fi
-
-    #
-    # Write the input and output commands to debug logs if it's asked for.
-    #
-    if [ "$SPACK_DEBUG" = TRUE ]; then
-        input_log="$SPACK_DEBUG_LOG_DIR/spack-cc-$SPACK_DEBUG_LOG_ID.in.log"
-        output_log="$SPACK_DEBUG_LOG_DIR/spack-cc-$SPACK_DEBUG_LOG_ID.out.log"
-        echo "[$mode] $command $input_command" >> "$input_log"
-        IFS="$lsep"
-        echo "[$mode] "$full_command_list >> "$output_log"
-        unset IFS
-    fi
-
-    # Execute the full command, preserving spaces with IFS set
-    # to the alarm bell separator.
-    IFS="$lsep"; exec $full_command_list
-    exit
+# system_dir PATH
+# test whether a path is a system directory
+system_dir() {
+    IFS=':'  # SPACK_SYSTEM_DIRS is colon-separated
+    path="$1"
+    for sd in $SPACK_SYSTEM_DIRS; do
+        if [ "${path}" = "${sd}" ] || [ "${path}" = "${sd}/" ]; then
+            # success if path starts with a system prefix
+            unset IFS
+            return 0
+        fi
+    done
+    unset IFS
+    return 1  # fail if path starts no system prefix
 }
 
 # Fail with a clear message if the input contains any bell characters.
@@ -225,48 +201,6 @@ for param in $params; do
     fi
 done
 
-# eval this because SPACK_MANAGED_DIRS and SPACK_SYSTEM_DIRS are inputs we don't wanna loop over.
-# moving the eval inside the function would eval it every call.
-eval "\
-path_order() {
-case \"\$1\" in
-    $SPACK_MANAGED_DIRS) return 0 ;;
-    $SPACK_SYSTEM_DIRS) return 2 ;;
-    /*) return 1 ;;
-esac
-}
-"
-
-# path_list functions. Path_lists have 3 parts: spack_store_<list>, <list> and system_<list>,
-# which are used to prioritize paths when assembling the final command line.
-
-# init_path_lists LISTNAME
-# Set <LISTNAME>, spack_store_<LISTNAME>, and system_<LISTNAME> to "".
-init_path_lists() {
-    eval "spack_store_$1=\"\""
-    eval "$1=\"\""
-    eval "system_$1=\"\""
-}
-
-# assign_path_lists LISTNAME1 LISTNAME2
-# Copy contents of LISTNAME2 into LISTNAME1, for each path_list prefix.
-assign_path_lists() {
-    eval "spack_store_$1=\"\${spack_store_$2}\""
-    eval "$1=\"\${$2}\""
-    eval "system_$1=\"\${system_$2}\""
-}
-
-# append_path_lists LISTNAME ELT
-# Append the provided ELT to the appropriate list, based on the result of path_order().
-append_path_lists() {
-    path_order "$2"
-    case $? in
-        0) eval "append spack_store_$1 \"\$2\"" ;;
-        1) eval "append $1 \"\$2\"" ;;
-        2) eval "append system_$1 \"\$2\"" ;;
-    esac
-}
-
 # Check if optional parameters are defined
 # If we aren't asking for debug flags, don't add them
 if [ -z "${SPACK_ADD_DEBUG_FLAGS:-}" ]; then
@@ -300,17 +234,12 @@ fi
 #    ld      link
 #    ccld    compile & link
 
-# Note. SPACK_ALWAYS_XFLAGS are applied for all compiler invocations,
-# including version checks (SPACK_XFLAGS variants are not applied
-# for version checks).
 command="${0##*/}"
 comp="CC"
-vcheck_flags=""
 case "$command" in
     cpp)
         mode=cpp
         debug_flags="-g"
-        vcheck_flags="${SPACK_ALWAYS_CPPFLAGS}"
         ;;
     cc|c89|c99|gcc|clang|armclang|icc|icx|pgcc|nvc|xlc|xlc_r|fcc|amdclang|cl.exe|craycc)
         command="$SPACK_CC"
@@ -318,15 +247,13 @@ case "$command" in
         comp="CC"
         lang_flags=C
         debug_flags="-g"
-        vcheck_flags="${SPACK_ALWAYS_CFLAGS}"
         ;;
-    c++|CC|g++|clang++|armclang++|icpc|icpx|pgc++|nvc++|xlc++|xlc++_r|FCC|amdclang++|crayCC)
+    c++|CC|g++|clang++|armclang++|icpc|icpx|dpcpp|pgc++|nvc++|xlc++|xlc++_r|FCC|amdclang++|crayCC)
         command="$SPACK_CXX"
         language="C++"
         comp="CXX"
         lang_flags=CXX
         debug_flags="-g"
-        vcheck_flags="${SPACK_ALWAYS_CXXFLAGS}"
         ;;
     ftn|f90|fc|f95|gfortran|flang|armflang|ifort|ifx|pgfortran|nvfortran|xlf90|xlf90_r|nagfor|frt|amdflang|crayftn)
         command="$SPACK_FC"
@@ -334,7 +261,6 @@ case "$command" in
         comp="FC"
         lang_flags=F
         debug_flags="-g"
-        vcheck_flags="${SPACK_ALWAYS_FFLAGS}"
         ;;
     f77|xlf|xlf_r|pgf77)
         command="$SPACK_F77"
@@ -342,7 +268,6 @@ case "$command" in
         comp="F77"
         lang_flags=F
         debug_flags="-g"
-        vcheck_flags="${SPACK_ALWAYS_FFLAGS}"
         ;;
     ld|ld.gold|ld.lld)
         mode=ld
@@ -443,11 +368,7 @@ unset IFS
 export PATH="$new_dirs"
 
 if [ "$mode" = vcheck ]; then
-    full_command_list="$command"
-    args="$@"
-    extend full_command_list vcheck_flags
-    extend full_command_list args
-    execute
+    exec "${command}" "$@"
 fi
 
 # Darwin's linker has a -r argument that merges object files together.
@@ -499,7 +420,11 @@ input_command="$*"
 parse_Wl() {
     while [ $# -ne 0 ]; do
     if [ "$wl_expect_rpath" = yes ]; then
-        append_path_lists return_rpath_dirs_list "$1"
+        if system_dir "$1"; then
+            append return_system_rpath_dirs_list "$1"
+        else
+            append return_rpath_dirs_list "$1"
+        fi
         wl_expect_rpath=no
     else
         case "$1" in
@@ -507,15 +432,21 @@ parse_Wl() {
                 arg="${1#-rpath=}"
                 if [ -z "$arg" ]; then
                     shift; continue
+                elif system_dir "$arg"; then
+                    append return_system_rpath_dirs_list "$arg"
+                else
+                    append return_rpath_dirs_list "$arg"
                 fi
-                append_path_lists return_rpath_dirs_list "$arg"
                 ;;
             --rpath=*)
                 arg="${1#--rpath=}"
                 if [ -z "$arg" ]; then
                     shift; continue
+                elif system_dir "$arg"; then
+                    append return_system_rpath_dirs_list "$arg"
+                else
+                    append return_rpath_dirs_list "$arg"
                 fi
-                append_path_lists return_rpath_dirs_list "$arg"
                 ;;
             -rpath|--rpath)
                 wl_expect_rpath=yes
@@ -523,7 +454,8 @@ parse_Wl() {
             "$dtags_to_strip")
                 ;;
             -Wl)
-                # Nested -Wl,-Wl means we're in NAG compiler territory. We don't support it.
+                # Nested -Wl,-Wl means we're in NAG compiler territory, we don't support
+                # it.
                 return 1
                 ;;
             *)
@@ -541,11 +473,14 @@ categorize_arguments() {
 
     return_other_args_list=""
     return_isystem_was_used=""
-
-    init_path_lists return_isystem_include_dirs_list
-    init_path_lists return_include_dirs_list
-    init_path_lists return_lib_dirs_list
-    init_path_lists return_rpath_dirs_list
+    return_isystem_system_include_dirs_list=""
+    return_isystem_include_dirs_list=""
+    return_system_include_dirs_list=""
+    return_include_dirs_list=""
+    return_system_lib_dirs_list=""
+    return_lib_dirs_list=""
+    return_system_rpath_dirs_list=""
+    return_rpath_dirs_list=""
 
     # Global state for keeping track of -Wl,-rpath -Wl,/path
     wl_expect_rpath=no
@@ -591,7 +526,7 @@ categorize_arguments() {
                     continue
                 fi
 
-                replaced="$after$stripped"
+                replaced="$after$stripped" 
 
                 # it matched, remove it
                 shift
@@ -611,17 +546,29 @@ categorize_arguments() {
                 arg="${1#-isystem}"
                 return_isystem_was_used=true
                 if [ -z "$arg" ]; then shift; arg="$1"; fi
-                append_path_lists return_isystem_include_dirs_list "$arg"
+                if system_dir "$arg"; then
+                    append return_isystem_system_include_dirs_list "$arg"
+                else
+                    append return_isystem_include_dirs_list "$arg"
+                fi
                 ;;
             -I*)
                 arg="${1#-I}"
                 if [ -z "$arg" ]; then shift; arg="$1"; fi
-                append_path_lists return_include_dirs_list "$arg"
+                if system_dir "$arg"; then
+                    append return_system_include_dirs_list "$arg"
+                else
+                    append return_include_dirs_list "$arg"
+                fi
                 ;;
             -L*)
                 arg="${1#-L}"
                 if [ -z "$arg" ]; then shift; arg="$1"; fi
-                append_path_lists return_lib_dirs_list "$arg"
+                if system_dir "$arg"; then
+                    append return_system_lib_dirs_list "$arg"
+                else
+                    append return_lib_dirs_list "$arg"
+                fi
                 ;;
             -l*)
                 # -loopopt=0 is generated erroneously in autoconf <= 2.69,
@@ -654,17 +601,29 @@ categorize_arguments() {
                     break
                 elif [ "$xlinker_expect_rpath" = yes ]; then
                     # Register the path of -Xlinker -rpath <other args> -Xlinker <path>
-                    append_path_lists return_rpath_dirs_list "$1"
+                    if system_dir "$1"; then
+                        append return_system_rpath_dirs_list "$1"
+                    else
+                        append return_rpath_dirs_list "$1"
+                    fi
                     xlinker_expect_rpath=no
                 else
                     case "$1" in
                         -rpath=*)
                             arg="${1#-rpath=}"
-                            append_path_lists return_rpath_dirs_list "$arg"
+                            if system_dir "$arg"; then
+                                append return_system_rpath_dirs_list "$arg"
+                            else
+                                append return_rpath_dirs_list "$arg"
+                            fi
                             ;;
                         --rpath=*)
                             arg="${1#--rpath=}"
-                            append_path_lists return_rpath_dirs_list "$arg"
+                            if system_dir "$arg"; then
+                                append return_system_rpath_dirs_list "$arg"
+                            else
+                                append return_rpath_dirs_list "$arg"
+                            fi
                             ;;
                         -rpath|--rpath)
                             xlinker_expect_rpath=yes
@@ -681,36 +640,7 @@ categorize_arguments() {
             "$dtags_to_strip")
                 ;;
             *)
-                # if mode is not ld, we can just add to other args
-                if [ "$mode" != "ld" ]; then
-                    append return_other_args_list "$1"
-                    shift
-                    continue
-                fi
-
-                # if we're in linker mode, we need to parse raw RPATH args
-                case "$1" in
-                    -rpath=*)
-                        arg="${1#-rpath=}"
-                        append_path_lists return_rpath_dirs_list "$arg"
-                        ;;
-                    --rpath=*)
-                        arg="${1#--rpath=}"
-                        append_path_lists return_rpath_dirs_list "$arg"
-                        ;;
-                    -rpath|--rpath)
-                        if [ $# -eq 1 ]; then
-                            # -rpath without value: let the linker raise an error.
-                            append return_other_args_list "$1"
-                            break
-                        fi
-                        shift
-                        append_path_lists return_rpath_dirs_list "$1"
-                        ;;
-                    *)
-                        append return_other_args_list "$1"
-                        ;;
-                esac
+                append return_other_args_list "$1"
                 ;;
         esac
         shift
@@ -731,14 +661,16 @@ categorize_arguments() {
 }
 
 categorize_arguments "$@"
-
-assign_path_lists isystem_include_dirs_list return_isystem_include_dirs_list
-assign_path_lists include_dirs_list return_include_dirs_list
-assign_path_lists lib_dirs_list return_lib_dirs_list
-assign_path_lists rpath_dirs_list return_rpath_dirs_list
-
-isystem_was_used="$return_isystem_was_used"
-other_args_list="$return_other_args_list"
+    include_dirs_list="$return_include_dirs_list"
+    lib_dirs_list="$return_lib_dirs_list"
+    rpath_dirs_list="$return_rpath_dirs_list"
+    system_include_dirs_list="$return_system_include_dirs_list"
+    system_lib_dirs_list="$return_system_lib_dirs_list"
+    system_rpath_dirs_list="$return_system_rpath_dirs_list"
+    isystem_was_used="$return_isystem_was_used"
+    isystem_system_include_dirs_list="$return_isystem_system_include_dirs_list"
+    isystem_include_dirs_list="$return_isystem_include_dirs_list"
+    other_args_list="$return_other_args_list"
 
 #
 # Add flags from Spack's cppflags, cflags, cxxflags, fcflags, fflags, and
@@ -765,7 +697,6 @@ case "$mode" in
     cc|ccld)
         case $lang_flags in
             F)
-                extend spack_flags_list SPACK_ALWAYS_FFLAGS
                 extend spack_flags_list SPACK_FFLAGS
                 ;;
         esac
@@ -775,7 +706,6 @@ esac
 # C preprocessor flags come before any C/CXX flags
 case "$mode" in
     cpp|as|cc|ccld)
-        extend spack_flags_list SPACK_ALWAYS_CPPFLAGS
         extend spack_flags_list SPACK_CPPFLAGS
         ;;
 esac
@@ -786,11 +716,9 @@ case "$mode" in
     cc|ccld)
         case $lang_flags in
             C)
-                extend spack_flags_list SPACK_ALWAYS_CFLAGS
                 extend spack_flags_list SPACK_CFLAGS
                 ;;
             CXX)
-                extend spack_flags_list SPACK_ALWAYS_CXXFLAGS
                 extend spack_flags_list SPACK_CXXFLAGS
                 ;;
         esac
@@ -802,7 +730,7 @@ esac
 
 # Linker flags
 case "$mode" in
-    ccld)
+    ld|ccld)
         extend spack_flags_list SPACK_LDFLAGS
         ;;
 esac
@@ -810,14 +738,16 @@ esac
 IFS="$lsep"
     categorize_arguments $spack_flags_list
 unset IFS
-
-assign_path_lists spack_flags_isystem_include_dirs_list return_isystem_include_dirs_list
-assign_path_lists spack_flags_include_dirs_list return_include_dirs_list
-assign_path_lists spack_flags_lib_dirs_list return_lib_dirs_list
-assign_path_lists spack_flags_rpath_dirs_list return_rpath_dirs_list
-
-spack_flags_isystem_was_used="$return_isystem_was_used"
-spack_flags_other_args_list="$return_other_args_list"
+        spack_flags_include_dirs_list="$return_include_dirs_list"
+        spack_flags_lib_dirs_list="$return_lib_dirs_list"
+        spack_flags_rpath_dirs_list="$return_rpath_dirs_list"
+        spack_flags_system_include_dirs_list="$return_system_include_dirs_list"
+        spack_flags_system_lib_dirs_list="$return_system_lib_dirs_list"
+        spack_flags_system_rpath_dirs_list="$return_system_rpath_dirs_list"
+        spack_flags_isystem_was_used="$return_isystem_was_used"
+        spack_flags_isystem_system_include_dirs_list="$return_isystem_system_include_dirs_list"
+        spack_flags_isystem_include_dirs_list="$return_isystem_include_dirs_list"
+        spack_flags_other_args_list="$return_other_args_list"
 
 
 # On macOS insert headerpad_max_install_names linker flag
@@ -837,13 +767,11 @@ if [ "$mode" = ccld ] || [ "$mode" = ld ]; then
         # Append RPATH directories. Note that in the case of the
         # top-level package these directories may not exist yet. For dependencies
         # it is assumed that paths have already been confirmed.
-        extend spack_store_rpath_dirs_list SPACK_STORE_RPATH_DIRS
         extend rpath_dirs_list SPACK_RPATH_DIRS
     fi
 fi
 
 if [ "$mode" = ccld ] || [ "$mode" = ld ]; then
-    extend spack_store_lib_dirs_list SPACK_STORE_LINK_DIRS
     extend lib_dirs_list SPACK_LINK_DIRS
 fi
 
@@ -870,82 +798,63 @@ case "$mode" in
         ;;
 esac
 
-case "$mode" in
-    cpp|cc|as|ccld)
-        if [ "$spack_flags_isystem_was_used" = "true" ] || [ "$isystem_was_used" = "true" ]; then
-            extend spack_store_isystem_include_dirs_list SPACK_STORE_INCLUDE_DIRS
-            extend isystem_include_dirs_list SPACK_INCLUDE_DIRS
-        else
-            extend spack_store_include_dirs_list SPACK_STORE_INCLUDE_DIRS
-            extend include_dirs_list SPACK_INCLUDE_DIRS
-        fi
-        ;;
-esac
-
 #
 # Finally, reassemble the command line.
 #
 args_list="$flags_list"
 
-# Include search paths partitioned by (in store, non-sytem, system)
+# Insert include directories just prior to any system include directories
 # NOTE: adding ${lsep} to the prefix here turns every added element into two
-extend args_list spack_store_spack_flags_include_dirs_list -I
-extend args_list spack_store_include_dirs_list -I
-
-extend args_list spack_flags_include_dirs_list -I
-extend args_list include_dirs_list -I
-
-extend args_list spack_store_spack_flags_isystem_include_dirs_list "-isystem${lsep}"
-extend args_list spack_store_isystem_include_dirs_list "-isystem${lsep}"
-
+extend args_list spack_flags_include_dirs_list "-I"
+extend args_list include_dirs_list "-I"
 extend args_list spack_flags_isystem_include_dirs_list "-isystem${lsep}"
 extend args_list isystem_include_dirs_list "-isystem${lsep}"
 
-extend args_list system_spack_flags_include_dirs_list -I
+case "$mode" in
+    cpp|cc|as|ccld)
+        if [ "$spack_flags_isystem_was_used" = "true" ]; then
+            extend args_list SPACK_INCLUDE_DIRS "-isystem${lsep}"
+        elif [ "$isystem_was_used" = "true" ]; then
+            extend args_list SPACK_INCLUDE_DIRS "-isystem${lsep}"
+        else
+            extend args_list SPACK_INCLUDE_DIRS "-I"
+        fi
+        ;;
+esac
+
+extend args_list spack_flags_system_include_dirs_list -I
 extend args_list system_include_dirs_list -I
+extend args_list spack_flags_isystem_system_include_dirs_list "-isystem${lsep}"
+extend args_list isystem_system_include_dirs_list "-isystem${lsep}"
 
-extend args_list system_spack_flags_isystem_include_dirs_list "-isystem${lsep}"
-extend args_list system_isystem_include_dirs_list "-isystem${lsep}"
-
-# Library search paths partitioned by (in store, non-sytem, system)
-extend args_list spack_store_spack_flags_lib_dirs_list "-L"
-extend args_list spack_store_lib_dirs_list "-L"
-
+# Library search paths
 extend args_list spack_flags_lib_dirs_list "-L"
 extend args_list lib_dirs_list "-L"
-
-extend args_list system_spack_flags_lib_dirs_list "-L"
+extend args_list spack_flags_system_lib_dirs_list "-L"
 extend args_list system_lib_dirs_list "-L"
 
 # RPATHs arguments
-rpath_prefix=""
 case "$mode" in
     ccld)
         if [ -n "$dtags_to_add" ] ; then
             append args_list "$linker_arg$dtags_to_add"
         fi
-        rpath_prefix="$rpath"
+        extend args_list spack_flags_rpath_dirs_list "$rpath"
+        extend args_list rpath_dirs_list "$rpath"
+        extend args_list spack_flags_system_rpath_dirs_list "$rpath"
+        extend args_list system_rpath_dirs_list "$rpath"
         ;;
     ld)
         if [ -n "$dtags_to_add" ] ; then
             append args_list "$dtags_to_add"
         fi
-        rpath_prefix="-rpath${lsep}"
+        extend args_list spack_flags_rpath_dirs_list "-rpath${lsep}"
+        extend args_list rpath_dirs_list "-rpath${lsep}"
+        extend args_list spack_flags_system_rpath_dirs_list "-rpath${lsep}"
+        extend args_list system_rpath_dirs_list "-rpath${lsep}"
         ;;
 esac
 
-# if mode is ccld or ld, extend RPATH lists with the prefix determined above
-if [ -n "$rpath_prefix" ]; then
-    extend args_list spack_store_spack_flags_rpath_dirs_list "$rpath_prefix"
-    extend args_list spack_store_rpath_dirs_list "$rpath_prefix"
-
-    extend args_list spack_flags_rpath_dirs_list "$rpath_prefix"
-    extend args_list rpath_dirs_list "$rpath_prefix"
-
-    extend args_list system_spack_flags_rpath_dirs_list "$rpath_prefix"
-    extend args_list system_rpath_dirs_list "$rpath_prefix"
-fi
-
 # Other arguments from the input command
 extend args_list other_args_list
 extend args_list spack_flags_other_args_list
@@ -968,4 +877,40 @@ if [ -n "$SPACK_CCACHE_BINARY" ]; then
     esac
 fi
 
-execute
+# dump the full command if the caller supplies SPACK_TEST_COMMAND=dump-args
+if [ -n "${SPACK_TEST_COMMAND=}" ]; then
+    case "$SPACK_TEST_COMMAND" in
+        dump-args)
+            IFS="$lsep"
+            for arg in $full_command_list; do
+                echo "$arg"
+            done
+            unset IFS
+            exit
+            ;;
+        dump-env-*)
+            var=${SPACK_TEST_COMMAND#dump-env-}
+            eval "printf '%s\n' \"\$0: \$var: \$$var\""
+            ;;
+        *)
+            die "Unknown test command: '$SPACK_TEST_COMMAND'"
+            ;;
+    esac
+fi
+
+#
+# Write the input and output commands to debug logs if it's asked for.
+#
+if [ "$SPACK_DEBUG" = TRUE ]; then
+    input_log="$SPACK_DEBUG_LOG_DIR/spack-cc-$SPACK_DEBUG_LOG_ID.in.log"
+    output_log="$SPACK_DEBUG_LOG_DIR/spack-cc-$SPACK_DEBUG_LOG_ID.out.log"
+    echo "[$mode] $command $input_command" >> "$input_log"
+    IFS="$lsep"
+    echo "[$mode] "$full_command_list >> "$output_log"
+    unset IFS
+fi
+
+# Execute the full command, preserving spaces with IFS set
+# to the alarm bell separator.
+IFS="$lsep"; exec $full_command_list
+

lib/spack/external/__init__.py

@@ -18,7 +18,7 @@
 
 * Homepage: https://pypi.python.org/pypi/archspec
 * Usage: Labeling, comparison and detection of microarchitectures
-* Version: 0.2.5 (commit 38ce485258ffc4fc6dd6688f8dc90cb269478c47)
+* Version: 0.2.2 (commit 1dc58a5776dd77e6fc6e4ba5626af5b1fb24996e)
 
 astunparse
 ----------------

lib/spack/external/_vendoring/distro/distro.py

@@ -1265,29 +1265,27 @@ def _distro_release_info(self) -> Dict[str, str]:
             match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename)
         else:
             try:
-                with os.scandir(self.etc_dir) as it:
-                    etc_files = [
-                        p.path for p in it
-                        if p.is_file() and p.name not in _DISTRO_RELEASE_IGNORE_BASENAMES
-                    ]
+                basenames = [
+                    basename
+                    for basename in os.listdir(self.etc_dir)
+                    if basename not in _DISTRO_RELEASE_IGNORE_BASENAMES
+                    and os.path.isfile(os.path.join(self.etc_dir, basename))
+                ]
                 # We sort for repeatability in cases where there are multiple
                 # distro specific files; e.g. CentOS, Oracle, Enterprise all
                 # containing `redhat-release` on top of their own.
-                etc_files.sort()
+                basenames.sort()
             except OSError:
                 # This may occur when /etc is not readable but we can't be
                 # sure about the *-release files. Check common entries of
                 # /etc for information. If they turn out to not be there the
                 # error is handled in `_parse_distro_release_file()`.
-                etc_files = [
-                    os.path.join(self.etc_dir, basename)
-                    for basename in _DISTRO_RELEASE_BASENAMES
-                ]
-
-            for filepath in etc_files:
-                match = _DISTRO_RELEASE_BASENAME_PATTERN.match(os.path.basename(filepath))
+                basenames = _DISTRO_RELEASE_BASENAMES
+            for basename in basenames:
+                match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename)
                 if match is None:
                     continue
+                filepath = os.path.join(self.etc_dir, basename)
                 distro_info = self._parse_distro_release_file(filepath)
                 # The name is always present if the pattern matches.
                 if "name" not in distro_info:

lib/spack/external/_vendoring/jsonschema/_format.py

@@ -231,6 +231,96 @@ def is_host_name(instance):
     return True
 
 
+try:
+    # The built-in `idna` codec only implements RFC 3890, so we go elsewhere.
+    import idna
+except ImportError:
+    pass
+else:
+    @_checks_drafts(draft7="idn-hostname", raises=idna.IDNAError)
+    def is_idn_host_name(instance):
+        if not isinstance(instance, str_types):
+            return True
+        idna.encode(instance)
+        return True
+
+
+try:
+    import rfc3987
+except ImportError:
+    try:
+        from rfc3986_validator import validate_rfc3986
+    except ImportError:
+        pass
+    else:
+        @_checks_drafts(name="uri")
+        def is_uri(instance):
+            if not isinstance(instance, str_types):
+                return True
+            return validate_rfc3986(instance, rule="URI")
+
+        @_checks_drafts(
+            draft6="uri-reference",
+            draft7="uri-reference",
+            raises=ValueError,
+        )
+        def is_uri_reference(instance):
+            if not isinstance(instance, str_types):
+                return True
+            return validate_rfc3986(instance, rule="URI_reference")
+
+else:
+    @_checks_drafts(draft7="iri", raises=ValueError)
+    def is_iri(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return rfc3987.parse(instance, rule="IRI")
+
+    @_checks_drafts(draft7="iri-reference", raises=ValueError)
+    def is_iri_reference(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return rfc3987.parse(instance, rule="IRI_reference")
+
+    @_checks_drafts(name="uri", raises=ValueError)
+    def is_uri(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return rfc3987.parse(instance, rule="URI")
+
+    @_checks_drafts(
+        draft6="uri-reference",
+        draft7="uri-reference",
+        raises=ValueError,
+    )
+    def is_uri_reference(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return rfc3987.parse(instance, rule="URI_reference")
+
+
+try:
+    from strict_rfc3339 import validate_rfc3339
+except ImportError:
+    try:
+        from rfc3339_validator import validate_rfc3339
+    except ImportError:
+        validate_rfc3339 = None
+
+if validate_rfc3339:
+    @_checks_drafts(name="date-time")
+    def is_datetime(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return validate_rfc3339(instance)
+
+    @_checks_drafts(draft7="time")
+    def is_time(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return is_datetime("1970-01-01T" + instance)
+
+
 @_checks_drafts(name="regex", raises=re.error)
 def is_regex(instance):
     if not isinstance(instance, str_types):
@@ -250,3 +340,86 @@ def is_draft3_time(instance):
     if not isinstance(instance, str_types):
         return True
     return datetime.datetime.strptime(instance, "%H:%M:%S")
+
+
+try:
+    import webcolors
+except ImportError:
+    pass
+else:
+    def is_css_color_code(instance):
+        return webcolors.normalize_hex(instance)
+
+    @_checks_drafts(draft3="color", raises=(ValueError, TypeError))
+    def is_css21_color(instance):
+        if (
+            not isinstance(instance, str_types) or
+            instance.lower() in webcolors.css21_names_to_hex
+        ):
+            return True
+        return is_css_color_code(instance)
+
+    def is_css3_color(instance):
+        if instance.lower() in webcolors.css3_names_to_hex:
+            return True
+        return is_css_color_code(instance)
+
+
+try:
+    import jsonpointer
+except ImportError:
+    pass
+else:
+    @_checks_drafts(
+        draft6="json-pointer",
+        draft7="json-pointer",
+        raises=jsonpointer.JsonPointerException,
+    )
+    def is_json_pointer(instance):
+        if not isinstance(instance, str_types):
+            return True
+        return jsonpointer.JsonPointer(instance)
+
+    # TODO: I don't want to maintain this, so it
+    #       needs to go either into jsonpointer (pending
+    #       https://github.com/stefankoegl/python-json-pointer/issues/34) or
+    #       into a new external library.
+    @_checks_drafts(
+        draft7="relative-json-pointer",
+        raises=jsonpointer.JsonPointerException,
+    )
+    def is_relative_json_pointer(instance):
+        # Definition taken from:
+        # https://tools.ietf.org/html/draft-handrews-relative-json-pointer-01#section-3
+        if not isinstance(instance, str_types):
+            return True
+        non_negative_integer, rest = [], ""
+        for i, character in enumerate(instance):
+            if character.isdigit():
+                non_negative_integer.append(character)
+                continue
+
+            if not non_negative_integer:
+                return False
+
+            rest = instance[i:]
+            break
+        return (rest == "#") or jsonpointer.JsonPointer(rest)
+
+
+try:
+    import uritemplate.exceptions
+except ImportError:
+    pass
+else:
+    @_checks_drafts(
+        draft6="uri-template",
+        draft7="uri-template",
+        raises=uritemplate.exceptions.InvalidTemplate,
+    )
+    def is_uri_template(
+        instance,
+        template_validator=uritemplate.Validator().force_balanced_braces(),
+    ):
+        template = uritemplate.URITemplate(instance)
+        return template_validator.validate(template)

lib/spack/external/_vendoring/ruamel/yaml/comments.py

@@ -497,7 +497,7 @@ def copy_attributes(self, t, memo=None):
                   Tag.attrib, merge_attrib]:
             if hasattr(self, a):
                 if memo is not None:
-                    setattr(t, a, copy.deepcopy(getattr(self, a), memo))
+                    setattr(t, a, copy.deepcopy(getattr(self, a, memo)))
                 else:
                     setattr(t, a, getattr(self, a))
         # fmt: on

lib/spack/external/archspec/__init__.py

@@ -1,3 +1,2 @@
 """Init file to avoid namespace packages"""
-
-__version__ = "0.2.4"
+__version__ = "0.2.2"

lib/spack/external/archspec/__main__.py

@@ -3,7 +3,6 @@
 """
 
 import sys
-
 from .cli import main
 
 sys.exit(main())

lib/spack/external/archspec/cli.py

@@ -46,11 +46,7 @@ def _make_parser() -> argparse.ArgumentParser:
 
 def cpu() -> int:
     """Run the `archspec cpu` subcommand."""
-    try:
-        print(archspec.cpu.host())
-    except FileNotFoundError as exc:
-        print(exc)
-        return 1
+    print(archspec.cpu.host())
     return 0
 
 

lib/spack/external/archspec/cpu/__init__.py

@@ -5,23 +5,16 @@
 """The "cpu" package permits to query and compare different
 CPU microarchitectures.
 """
-from .detect import brand_string, host
-from .microarchitecture import (
-    TARGETS,
-    InvalidCompilerVersion,
-    Microarchitecture,
-    UnsupportedMicroarchitecture,
-    generic_microarchitecture,
-    version_components,
-)
+from .microarchitecture import Microarchitecture, UnsupportedMicroarchitecture
+from .microarchitecture import TARGETS, generic_microarchitecture
+from .microarchitecture import version_components
+from .detect import host
 
 __all__ = [
-    "brand_string",
-    "host",
-    "TARGETS",
-    "InvalidCompilerVersion",
     "Microarchitecture",
     "UnsupportedMicroarchitecture",
+    "TARGETS",
     "generic_microarchitecture",
+    "host",
     "version_components",
 ]

lib/spack/external/archspec/cpu/detect.py

@@ -4,17 +4,15 @@
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 """Detection of CPU microarchitectures"""
 import collections
+import functools
 import os
 import platform
 import re
-import struct
 import subprocess
 import warnings
-from typing import Dict, List, Optional, Set, Tuple, Union
 
-from ..vendor.cpuid.cpuid import CPUID
-from .microarchitecture import TARGETS, Microarchitecture, generic_microarchitecture
-from .schema import CPUID_JSON, TARGETS_JSON
+from .microarchitecture import generic_microarchitecture, TARGETS
+from .schema import TARGETS_JSON
 
 #: Mapping from operating systems to chain of commands
 #: to obtain a dictionary of raw info on the current cpu
@@ -24,51 +22,43 @@
 #: functions checking the compatibility of the host with a given target
 COMPATIBILITY_CHECKS = {}
 
-# Constants for commonly used architectures
-X86_64 = "x86_64"
-AARCH64 = "aarch64"
-PPC64LE = "ppc64le"
-PPC64 = "ppc64"
-RISCV64 = "riscv64"
 
-
-def detection(operating_system: str):
-    """Decorator to mark functions that are meant to return partial information on the current cpu.
+def info_dict(operating_system):
+    """Decorator to mark functions that are meant to return raw info on
+    the current cpu.
 
     Args:
-        operating_system: operating system where this function can be used.
+        operating_system (str or tuple): operating system for which the marked
+            function is a viable factory of raw info dictionaries.
     """
 
     def decorator(factory):
         INFO_FACTORY[operating_system].append(factory)
-        return factory
+
+        @functools.wraps(factory)
+        def _impl():
+            info = factory()
+
+            # Check that info contains a few mandatory fields
+            msg = 'field "{0}" is missing from raw info dictionary'
+            assert "vendor_id" in info, msg.format("vendor_id")
+            assert "flags" in info, msg.format("flags")
+            assert "model" in info, msg.format("model")
+            assert "model_name" in info, msg.format("model_name")
+
+            return info
+
+        return _impl
 
     return decorator
 
 
-def partial_uarch(
-    name: str = "",
-    vendor: str = "",
-    features: Optional[Set[str]] = None,
-    generation: int = 0,
-    cpu_part: str = "",
-) -> Microarchitecture:
-    """Construct a partial microarchitecture, from information gathered during system scan."""
-    return Microarchitecture(
-        name=name,
-        parents=[],
-        vendor=vendor,
-        features=features or set(),
-        compilers={},
-        generation=generation,
-        cpu_part=cpu_part,
-    )
-
-
-@detection(operating_system="Linux")
-def proc_cpuinfo() -> Microarchitecture:
-    """Returns a partial Microarchitecture, obtained from scanning ``/proc/cpuinfo``"""
-    data = {}
+@info_dict(operating_system="Linux")
+def proc_cpuinfo():
+    """Returns a raw info dictionary by parsing the first entry of
+    ``/proc/cpuinfo``
+    """
+    info = {}
     with open("/proc/cpuinfo") as file:  # pylint: disable=unspecified-encoding
         for line in file:
             key, separator, value = line.partition(":")
@@ -80,122 +70,11 @@ def proc_cpuinfo() -> Microarchitecture:
             #
             # we are on a blank line separating two cpus. Exit early as
             # we want to read just the first entry in /proc/cpuinfo
-            if separator != ":" and data:
+            if separator != ":" and info:
                 break
 
-            data[key.strip()] = value.strip()
-
-    architecture = _machine()
-    if architecture == X86_64:
-        return partial_uarch(
-            vendor=data.get("vendor_id", "generic"), features=_feature_set(data, key="flags")
-        )
-
-    if architecture == AARCH64:
-        return partial_uarch(
-            vendor=_canonicalize_aarch64_vendor(data),
-            features=_feature_set(data, key="Features"),
-            cpu_part=data.get("CPU part", ""),
-        )
-
-    if architecture in (PPC64LE, PPC64):
-        generation_match = re.search(r"POWER(\d+)", data.get("cpu", ""))
-        try:
-            generation = int(generation_match.group(1))
-        except AttributeError:
-            # There might be no match under emulated environments. For instance
-            # emulating a ppc64le with QEMU and Docker still reports the host
-            # /proc/cpuinfo and not a Power
-            generation = 0
-        return partial_uarch(generation=generation)
-
-    if architecture == RISCV64:
-        if data.get("uarch") == "sifive,u74-mc":
-            data["uarch"] = "u74mc"
-        return partial_uarch(name=data.get("uarch", RISCV64))
-
-    return generic_microarchitecture(architecture)
-
-
-class CpuidInfoCollector:
-    """Collects the information we need on the host CPU from cpuid"""
-
-    # pylint: disable=too-few-public-methods
-    def __init__(self):
-        self.cpuid = CPUID()
-
-        registers = self.cpuid.registers_for(**CPUID_JSON["vendor"]["input"])
-        self.highest_basic_support = registers.eax
-        self.vendor = struct.pack("III", registers.ebx, registers.edx, registers.ecx).decode(
-            "utf-8"
-        )
-
-        registers = self.cpuid.registers_for(**CPUID_JSON["highest_extension_support"]["input"])
-        self.highest_extension_support = registers.eax
-
-        self.features = self._features()
-
-    def _features(self):
-        result = set()
-
-        def check_features(data):
-            registers = self.cpuid.registers_for(**data["input"])
-            for feature_check in data["bits"]:
-                current = getattr(registers, feature_check["register"])
-                if self._is_bit_set(current, feature_check["bit"]):
-                    result.add(feature_check["name"])
-
-        for call_data in CPUID_JSON["flags"]:
-            if call_data["input"]["eax"] > self.highest_basic_support:
-                continue
-            check_features(call_data)
-
-        for call_data in CPUID_JSON["extension-flags"]:
-            if call_data["input"]["eax"] > self.highest_extension_support:
-                continue
-            check_features(call_data)
-
-        return result
-
-    def _is_bit_set(self, register: int, bit: int) -> bool:
-        mask = 1 << bit
-        return register & mask > 0
-
-    def brand_string(self) -> Optional[str]:
-        """Returns the brand string, if available."""
-        if self.highest_extension_support < 0x80000004:
-            return None
-
-        r1 = self.cpuid.registers_for(eax=0x80000002, ecx=0)
-        r2 = self.cpuid.registers_for(eax=0x80000003, ecx=0)
-        r3 = self.cpuid.registers_for(eax=0x80000004, ecx=0)
-        result = struct.pack(
-            "IIIIIIIIIIII",
-            r1.eax,
-            r1.ebx,
-            r1.ecx,
-            r1.edx,
-            r2.eax,
-            r2.ebx,
-            r2.ecx,
-            r2.edx,
-            r3.eax,
-            r3.ebx,
-            r3.ecx,
-            r3.edx,
-        ).decode("utf-8")
-        return result.strip("\x00")
-
-
-@detection(operating_system="Windows")
-def cpuid_info():
-    """Returns a partial Microarchitecture, obtained from running the cpuid instruction"""
-    architecture = _machine()
-    if architecture == X86_64:
-        data = CpuidInfoCollector()
-        return partial_uarch(vendor=data.vendor, features=data.features)
-
-    return generic_microarchitecture(architecture)
+            info[key.strip()] = value.strip()
+    return info
 
 
 def _check_output(args, env):
@@ -204,25 +83,14 @@ def _check_output(args, env):
     return str(output.decode("utf-8"))
 
 
-WINDOWS_MAPPING = {
-    "AMD64": X86_64,
-    "ARM64": AARCH64,
-}
-
-
 def _machine():
-    """Return the machine architecture we are on"""
+    """ "Return the machine architecture we are on"""
     operating_system = platform.system()
 
-    # If we are not on Darwin or Windows, trust what Python tells us
-    if operating_system not in ("Darwin", "Windows"):
+    # If we are not on Darwin, trust what Python tells us
+    if operating_system != "Darwin":
         return platform.machine()
 
-    # Normalize windows specific names
-    if operating_system == "Windows":
-        platform_machine = platform.machine()
-        return WINDOWS_MAPPING.get(platform_machine, platform_machine)
-
     # On Darwin it might happen that we are on M1, but using an interpreter
     # built for x86_64. In that case "platform.machine() == 'x86_64'", so we
     # need to fix that.
@@ -235,47 +103,54 @@ def _machine():
     if "Apple" in output:
         # Note that a native Python interpreter on Apple M1 would return
         # "arm64" instead of "aarch64". Here we normalize to the latter.
-        return AARCH64
+        return "aarch64"
 
-    return X86_64
+    return "x86_64"
 
 
-@detection(operating_system="Darwin")
-def sysctl_info() -> Microarchitecture:
+@info_dict(operating_system="Darwin")
+def sysctl_info_dict():
     """Returns a raw info dictionary parsing the output of sysctl."""
     child_environment = _ensure_bin_usrbin_in_path()
 
-    def sysctl(*args: str) -> str:
+    def sysctl(*args):
         return _check_output(["sysctl"] + list(args), env=child_environment).strip()
 
-    if _machine() == X86_64:
-        features = (
-            f'{sysctl("-n", "machdep.cpu.features").lower()} '
-            f'{sysctl("-n", "machdep.cpu.leaf7_features").lower()}'
+    if _machine() == "x86_64":
+        flags = (
+            sysctl("-n", "machdep.cpu.features").lower()
+            + " "
+            + sysctl("-n", "machdep.cpu.leaf7_features").lower()
         )
-        features = set(features.split())
+        info = {
+            "vendor_id": sysctl("-n", "machdep.cpu.vendor"),
+            "flags": flags,
+            "model": sysctl("-n", "machdep.cpu.model"),
+            "model name": sysctl("-n", "machdep.cpu.brand_string"),
+        }
+    else:
+        model = "unknown"
+        model_str = sysctl("-n", "machdep.cpu.brand_string").lower()
+        if "m2" in model_str:
+            model = "m2"
+        elif "m1" in model_str:
+            model = "m1"
+        elif "apple" in model_str:
+            model = "m1"
 
-        # Flags detected on Darwin turned to their linux counterpart
-        for darwin_flag, linux_flag in TARGETS_JSON["conversions"]["darwin_flags"].items():
-            if darwin_flag in features:
-                features.update(linux_flag.split())
-
-        return partial_uarch(vendor=sysctl("-n", "machdep.cpu.vendor"), features=features)
-
-    model = "unknown"
-    model_str = sysctl("-n", "machdep.cpu.brand_string").lower()
-    if "m2" in model_str:
-        model = "m2"
-    elif "m1" in model_str:
-        model = "m1"
-    elif "apple" in model_str:
-        model = "m1"
-
-    return partial_uarch(name=model, vendor="Apple")
+        info = {
+            "vendor_id": "Apple",
+            "flags": [],
+            "model": model,
+            "CPU implementer": "Apple",
+            "model name": sysctl("-n", "machdep.cpu.brand_string"),
+        }
+    return info
 
 
 def _ensure_bin_usrbin_in_path():
-    # Make sure that /sbin and /usr/sbin are in PATH as sysctl is usually found there
+    # Make sure that /sbin and /usr/sbin are in PATH as sysctl is
+    # usually found there
     child_environment = dict(os.environ.items())
     search_paths = child_environment.get("PATH", "").split(os.pathsep)
     for additional_path in ("/sbin", "/usr/sbin"):
@@ -285,10 +160,22 @@ def _ensure_bin_usrbin_in_path():
     return child_environment
 
 
-def _canonicalize_aarch64_vendor(data: Dict[str, str]) -> str:
-    """Adjust the vendor field to make it human-readable"""
-    if "CPU implementer" not in data:
-        return "generic"
+def adjust_raw_flags(info):
+    """Adjust the flags detected on the system to homogenize
+    slightly different representations.
+    """
+    # Flags detected on Darwin turned to their linux counterpart
+    flags = info.get("flags", [])
+    d2l = TARGETS_JSON["conversions"]["darwin_flags"]
+    for darwin_flag, linux_flag in d2l.items():
+        if darwin_flag in flags:
+            info["flags"] += " " + linux_flag
+
+
+def adjust_raw_vendor(info):
+    """Adjust the vendor field to make it human readable"""
+    if "CPU implementer" not in info:
+        return
 
     # Mapping numeric codes to vendor (ARM). This list is a merge from
     # different sources:
@@ -298,37 +185,43 @@ def _canonicalize_aarch64_vendor(data: Dict[str, str]) -> str:
     # https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64-cores.def
     # https://patchwork.kernel.org/patch/10524949/
     arm_vendors = TARGETS_JSON["conversions"]["arm_vendors"]
-    arm_code = data["CPU implementer"]
-    return arm_vendors.get(arm_code, arm_code)
+    arm_code = info["CPU implementer"]
+    if arm_code in arm_vendors:
+        info["CPU implementer"] = arm_vendors[arm_code]
 
 
-def _feature_set(data: Dict[str, str], key: str) -> Set[str]:
-    return set(data.get(key, "").split())
+def raw_info_dictionary():
+    """Returns a dictionary with information on the cpu of the current host.
 
-
-def detected_info() -> Microarchitecture:
-    """Returns a partial Microarchitecture with information on the CPU of the current host.
-
-    This function calls all the viable factories one after the other until there's one that is
-    able to produce the requested information. Falls-back to a generic microarchitecture, if none
-    of the calls succeed.
+    This function calls all the viable factories one after the other until
+    there's one that is able to produce the requested information.
     """
     # pylint: disable=broad-except
+    info = {}
     for factory in INFO_FACTORY[platform.system()]:
         try:
-            return factory()
+            info = factory()
         except Exception as exc:
             warnings.warn(str(exc))
 
-    return generic_microarchitecture(_machine())
+        if info:
+            adjust_raw_flags(info)
+            adjust_raw_vendor(info)
+            break
+
+    return info
 
 
-def compatible_microarchitectures(info: Microarchitecture) -> List[Microarchitecture]:
-    """Returns an unordered list of known micro-architectures that are compatible with the
-    partial Microarchitecture passed as input.
+def compatible_microarchitectures(info):
+    """Returns an unordered list of known micro-architectures that are
+    compatible with the info dictionary passed as argument.
+
+    Args:
+        info (dict): dictionary containing information on the host cpu
     """
     architecture_family = _machine()
-    # If a tester is not registered, assume no known target is compatible with the host
+    # If a tester is not registered, be conservative and assume no known
+    # target is compatible with the host
     tester = COMPATIBILITY_CHECKS.get(architecture_family, lambda x, y: False)
     return [x for x in TARGETS.values() if tester(info, x)] or [
         generic_microarchitecture(architecture_family)
@@ -337,8 +230,8 @@ def compatible_microarchitectures(info: Microarchitecture) -> List[Microarchitec
 
 def host():
     """Detects the host micro-architecture and returns it."""
-    # Retrieve information on the host's cpu
-    info = detected_info()
+    # Retrieve a dictionary with raw information on the host's cpu
+    info = raw_info_dictionary()
 
     # Get a list of possible candidates for this micro-architecture
     candidates = compatible_microarchitectures(info)
@@ -351,10 +244,6 @@ def sorting_fn(item):
     generic_candidates = [c for c in candidates if c.vendor == "generic"]
     best_generic = max(generic_candidates, key=sorting_fn)
 
-    # Relevant for AArch64. Filter on "cpu_part" if we have any match
-    if info.cpu_part != "" and any(c for c in candidates if info.cpu_part == c.cpu_part):
-        candidates = [c for c in candidates if info.cpu_part == c.cpu_part]
-
     # Filter the candidates to be descendant of the best generic candidate.
     # This is to avoid that the lack of a niche feature that can be disabled
     # from e.g. BIOS prevents detection of a reasonably performant architecture
@@ -369,15 +258,16 @@ def sorting_fn(item):
     return max(candidates, key=sorting_fn)
 
 
-def compatibility_check(architecture_family: Union[str, Tuple[str, ...]]):
+def compatibility_check(architecture_family):
     """Decorator to register a function as a proper compatibility check.
 
-    A compatibility check function takes a partial Microarchitecture object as a first argument,
-    and an arbitrary target Microarchitecture as the second argument. It returns True if the
-    target is compatible with first argument, False otherwise.
+    A compatibility check function takes the raw info dictionary as a first
+    argument and an arbitrary target as the second argument. It returns True
+    if the target is compatible with the info dictionary, False otherwise.
 
     Args:
-        architecture_family: architecture family for which this test can be used
+        architecture_family (str or tuple): architecture family for which
+            this test can be used, e.g. x86_64 or ppc64le etc.
     """
     # Turn the argument into something iterable
     if isinstance(architecture_family, str):
@@ -390,70 +280,86 @@ def decorator(func):
     return decorator
 
 
-@compatibility_check(architecture_family=(PPC64LE, PPC64))
+@compatibility_check(architecture_family=("ppc64le", "ppc64"))
 def compatibility_check_for_power(info, target):
     """Compatibility check for PPC64 and PPC64LE architectures."""
+    basename = platform.machine()
+    generation_match = re.search(r"POWER(\d+)", info.get("cpu", ""))
+    try:
+        generation = int(generation_match.group(1))
+    except AttributeError:
+        # There might be no match under emulated environments. For instance
+        # emulating a ppc64le with QEMU and Docker still reports the host
+        # /proc/cpuinfo and not a Power
+        generation = 0
+
     # We can use a target if it descends from our machine type and our
     # generation (9 for POWER9, etc) is at least its generation.
-    arch_root = TARGETS[_machine()]
+    arch_root = TARGETS[basename]
     return (
         target == arch_root or arch_root in target.ancestors
-    ) and target.generation <= info.generation
+    ) and target.generation <= generation
 
 
-@compatibility_check(architecture_family=X86_64)
+@compatibility_check(architecture_family="x86_64")
 def compatibility_check_for_x86_64(info, target):
     """Compatibility check for x86_64 architectures."""
+    basename = "x86_64"
+    vendor = info.get("vendor_id", "generic")
+    features = set(info.get("flags", "").split())
+
     # We can use a target if it descends from our machine type, is from our
     # vendor, and we have all of its features
-    arch_root = TARGETS[X86_64]
+    arch_root = TARGETS[basename]
     return (
         (target == arch_root or arch_root in target.ancestors)
-        and target.vendor in (info.vendor, "generic")
-        and target.features.issubset(info.features)
+        and target.vendor in (vendor, "generic")
+        and target.features.issubset(features)
     )
 
 
-@compatibility_check(architecture_family=AARCH64)
+@compatibility_check(architecture_family="aarch64")
 def compatibility_check_for_aarch64(info, target):
     """Compatibility check for AARCH64 architectures."""
-    # At the moment, it's not clear how to detect compatibility with
+    basename = "aarch64"
+    features = set(info.get("Features", "").split())
+    vendor = info.get("CPU implementer", "generic")
+
+    # At the moment it's not clear how to detect compatibility with
     # a specific version of the architecture
-    if target.vendor == "generic" and target.name != AARCH64:
+    if target.vendor == "generic" and target.name != "aarch64":
         return False
 
-    arch_root = TARGETS[AARCH64]
+    arch_root = TARGETS[basename]
     arch_root_and_vendor = arch_root == target.family and target.vendor in (
-        info.vendor,
+        vendor,
         "generic",
     )
 
     # On macOS it seems impossible to get all the CPU features
     # with syctl info, but for ARM we can get the exact model
     if platform.system() == "Darwin":
-        model = TARGETS[info.name]
+        model_key = info.get("model", basename)
+        model = TARGETS[model_key]
         return arch_root_and_vendor and (target == model or target in model.ancestors)
 
-    return arch_root_and_vendor and target.features.issubset(info.features)
+    return arch_root_and_vendor and target.features.issubset(features)
 
 
-@compatibility_check(architecture_family=RISCV64)
+@compatibility_check(architecture_family="riscv64")
 def compatibility_check_for_riscv64(info, target):
     """Compatibility check for riscv64 architectures."""
-    arch_root = TARGETS[RISCV64]
+    basename = "riscv64"
+    uarch = info.get("uarch")
+
+    # sifive unmatched board
+    if uarch == "sifive,u74-mc":
+        uarch = "u74mc"
+    # catch-all for unknown uarchs
+    else:
+        uarch = "riscv64"
+
+    arch_root = TARGETS[basename]
     return (target == arch_root or arch_root in target.ancestors) and (
-        target.name == info.name or target.vendor == "generic"
+        target == uarch or target.vendor == "generic"
     )
-
-
-def brand_string() -> Optional[str]:
-    """Returns the brand string of the host, if detected, or None."""
-    if platform.system() == "Darwin":
-        return _check_output(
-            ["sysctl", "-n", "machdep.cpu.brand_string"], env=_ensure_bin_usrbin_in_path()
-        ).strip()
-
-    if host().family == X86_64:
-        return CpuidInfoCollector().brand_string()
-
-    return None

lib/spack/external/archspec/cpu/microarchitecture.py

@@ -2,7 +2,9 @@
 # Archspec Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
-"""Types and functions to manage information on CPU microarchitectures."""
+"""Types and functions to manage information
+on CPU microarchitectures.
+"""
 import functools
 import platform
 import re
@@ -11,7 +13,6 @@
 import archspec
 import archspec.cpu.alias
 import archspec.cpu.schema
-
 from .alias import FEATURE_ALIASES
 from .schema import LazyDictionary
 
@@ -46,7 +47,7 @@ class Microarchitecture:
             which has "broadwell" as a parent, supports running binaries
             optimized for "broadwell".
         vendor (str): vendor of the micro-architecture
-        features (set of str): supported CPU flags. Note that the semantic
+        features (list of str): supported CPU flags. Note that the semantic
             of the flags in this field might vary among architectures, if
             at all present. For instance x86_64 processors will list all
             the flags supported by a given CPU while Arm processors will
@@ -63,31 +64,23 @@ class Microarchitecture:
                 passed in as argument above.
             * versions: versions that support this micro-architecture.
 
-        generation (int): generation of the micro-architecture, if relevant.
-        cpu_part (str): cpu part of the architecture, if relevant.
+        generation (int): generation of the micro-architecture, if
+            relevant.
     """
 
-    # pylint: disable=too-many-arguments,too-many-instance-attributes
+    # pylint: disable=too-many-arguments
     #: Aliases for micro-architecture's features
     feature_aliases = FEATURE_ALIASES
 
-    def __init__(self, name, parents, vendor, features, compilers, generation=0, cpu_part=""):
+    def __init__(self, name, parents, vendor, features, compilers, generation=0):
         self.name = name
         self.parents = parents
         self.vendor = vendor
         self.features = features
         self.compilers = compilers
-        # Only relevant for PowerPC
         self.generation = generation
-        # Only relevant for AArch64
-        self.cpu_part = cpu_part
-
-        # Cache the "ancestor" computation
+        # Cache the ancestor computation
         self._ancestors = None
-        # Cache the "generic" computation
-        self._generic = None
-        # Cache the "family" computation
-        self._family = None
 
     @property
     def ancestors(self):
@@ -117,12 +110,8 @@ def __eq__(self, other):
             and self.parents == other.parents  # avoid ancestors here
             and self.compilers == other.compilers
             and self.generation == other.generation
-            and self.cpu_part == other.cpu_part
         )
 
-    def __hash__(self):
-        return hash(self.name)
-
     @coerce_target_names
     def __ne__(self, other):
         return not self == other
@@ -153,8 +142,7 @@ def __repr__(self):
         cls_name = self.__class__.__name__
         fmt = (
             cls_name + "({0.name!r}, {0.parents!r}, {0.vendor!r}, "
-            "{0.features!r}, {0.compilers!r}, generation={0.generation!r}, "
-            "cpu_part={0.cpu_part!r})"
+            "{0.features!r}, {0.compilers!r}, {0.generation!r})"
         )
         return fmt.format(self)
 
@@ -179,54 +167,42 @@ def __contains__(self, feature):
     @property
     def family(self):
         """Returns the architecture family a given target belongs to"""
-        if self._family is None:
-            roots = [x for x in [self] + self.ancestors if not x.ancestors]
-            msg = "a target is expected to belong to just one architecture family"
-            msg += f"[found {', '.join(str(x) for x in roots)}]"
-            assert len(roots) == 1, msg
-            self._family = roots.pop()
+        roots = [x for x in [self] + self.ancestors if not x.ancestors]
+        msg = "a target is expected to belong to just one architecture family"
+        msg += f"[found {', '.join(str(x) for x in roots)}]"
+        assert len(roots) == 1, msg
 
-        return self._family
+        return roots.pop()
 
     @property
     def generic(self):
         """Returns the best generic architecture that is compatible with self"""
-        if self._generic is None:
-            generics = [x for x in [self] + self.ancestors if x.vendor == "generic"]
-            self._generic = max(generics, key=lambda x: len(x.ancestors))
-        return self._generic
+        generics = [x for x in [self] + self.ancestors if x.vendor == "generic"]
+        return max(generics, key=lambda x: len(x.ancestors))
 
-    def to_dict(self):
-        """Returns a dictionary representation of this object."""
-        return {
-            "name": str(self.name),
-            "vendor": str(self.vendor),
-            "features": sorted(str(x) for x in self.features),
-            "generation": self.generation,
-            "parents": [str(x) for x in self.parents],
-            "compilers": self.compilers,
-            "cpupart": self.cpu_part,
-        }
+    def to_dict(self, return_list_of_items=False):
+        """Returns a dictionary representation of this object.
 
-    @staticmethod
-    def from_dict(data) -> "Microarchitecture":
-        """Construct a microarchitecture from a dictionary representation."""
-        return Microarchitecture(
-            name=data["name"],
-            parents=[TARGETS[x] for x in data["parents"]],
-            vendor=data["vendor"],
-            features=set(data["features"]),
-            compilers=data.get("compilers", {}),
-            generation=data.get("generation", 0),
-            cpu_part=data.get("cpupart", ""),
-        )
+        Args:
+            return_list_of_items (bool): if True returns an ordered list of
+                items instead of the dictionary
+        """
+        list_of_items = [
+            ("name", str(self.name)),
+            ("vendor", str(self.vendor)),
+            ("features", sorted(str(x) for x in self.features)),
+            ("generation", self.generation),
+            ("parents", [str(x) for x in self.parents]),
+        ]
+        if return_list_of_items:
+            return list_of_items
+
+        return dict(list_of_items)
 
     def optimization_flags(self, compiler, version):
         """Returns a string containing the optimization flags that needs
         to be used to produce code optimized for this micro-architecture.
 
-        The version is expected to be a string of dot separated digits.
-
         If there is no information on the compiler passed as argument the
         function returns an empty string. If it is known that the compiler
         version we want to use does not support this architecture the function
@@ -235,11 +211,6 @@ def optimization_flags(self, compiler, version):
         Args:
             compiler (str): name of the compiler to be used
             version (str): version of the compiler to be used
-
-        Raises:
-            UnsupportedMicroarchitecture: if the requested compiler does not support
-                this micro-architecture.
-            ValueError: if the version doesn't match the expected format
         """
         # If we don't have information on compiler at all return an empty string
         if compiler not in self.family.compilers:
@@ -256,14 +227,6 @@ def optimization_flags(self, compiler, version):
             msg = msg.format(compiler, best_target, best_target.family)
             raise UnsupportedMicroarchitecture(msg)
 
-        # Check that the version matches the expected format
-        if not re.match(r"^(?:\d+\.)*\d+$", version):
-            msg = (
-                "invalid format for the compiler version argument. "
-                "Only dot separated digits are allowed."
-            )
-            raise InvalidCompilerVersion(msg)
-
         # If we have information on this compiler we need to check the
         # version being used
         compiler_info = self.compilers[compiler]
@@ -308,7 +271,9 @@ def tuplify(ver):
                 flags = flags_fmt.format(**compiler_entry)
                 return flags
 
-        msg = "cannot produce optimized binary for micro-architecture '{0}' with {1}@{2}"
+        msg = (
+            "cannot produce optimized binary for micro-architecture '{0}' with {1}@{2}"
+        )
         if compiler_info:
             versions = [x["versions"] for x in compiler_info]
             msg += f' [supported compiler versions are {", ".join(versions)}]'
@@ -324,7 +289,9 @@ def generic_microarchitecture(name):
     Args:
         name (str): name of the micro-architecture
     """
-    return Microarchitecture(name, parents=[], vendor="generic", features=set(), compilers={})
+    return Microarchitecture(
+        name, parents=[], vendor="generic", features=[], compilers={}
+    )
 
 
 def version_components(version):
@@ -377,10 +344,9 @@ def fill_target_from_dict(name, data, targets):
         features = set(values["features"])
         compilers = values.get("compilers", {})
         generation = values.get("generation", 0)
-        cpu_part = values.get("cpupart", "")
 
         targets[name] = Microarchitecture(
-            name, parents, vendor, features, compilers, generation=generation, cpu_part=cpu_part
+            name, parents, vendor, features, compilers, generation
         )
 
     known_targets = {}
@@ -402,15 +368,7 @@ def fill_target_from_dict(name, data, targets):
 TARGETS = LazyDictionary(_known_microarchitectures)
 
 
-class ArchspecError(Exception):
-    """Base class for errors within archspec"""
-
-
-class UnsupportedMicroarchitecture(ArchspecError, ValueError):
+class UnsupportedMicroarchitecture(ValueError):
     """Raised if a compiler version does not support optimization for a given
     micro-architecture.
     """
-
-
-class InvalidCompilerVersion(ArchspecError, ValueError):
-    """Raised when an invalid format is used for compiler versions in archspec."""

lib/spack/external/archspec/cpu/schema.py

@@ -7,9 +7,7 @@
 """
 import collections.abc
 import json
-import os
-import pathlib
-from typing import Tuple
+import os.path
 
 
 class LazyDictionary(collections.abc.MutableMapping):
@@ -48,65 +46,21 @@ def __len__(self):
         return len(self.data)
 
 
-#: Environment variable that might point to a directory with a user defined JSON file
-DIR_FROM_ENVIRONMENT = "ARCHSPEC_CPU_DIR"
+def _load_json_file(json_file):
+    json_dir = os.path.join(os.path.dirname(__file__), "..", "json", "cpu")
+    json_dir = os.path.abspath(json_dir)
 
-#: Environment variable that might point to a directory with extensions to JSON files
-EXTENSION_DIR_FROM_ENVIRONMENT = "ARCHSPEC_EXTENSION_CPU_DIR"
+    def _factory():
+        filename = os.path.join(json_dir, json_file)
+        with open(filename, "r", encoding="utf-8") as file:
+            return json.load(file)
 
-
-def _json_file(filename: str, allow_custom: bool = False) -> Tuple[pathlib.Path, pathlib.Path]:
-    """Given a filename, returns the absolute path for the main JSON file, and an
-    optional absolute path for an extension JSON file.
-
-    Args:
-        filename: filename for the JSON file
-        allow_custom: if True, allows overriding the location  where the file resides
-    """
-    json_dir = pathlib.Path(__file__).parent / ".." / "json" / "cpu"
-    if allow_custom and DIR_FROM_ENVIRONMENT in os.environ:
-        json_dir = pathlib.Path(os.environ[DIR_FROM_ENVIRONMENT])
-    json_dir = json_dir.absolute()
-    json_file = json_dir / filename
-
-    extension_file = None
-    if allow_custom and EXTENSION_DIR_FROM_ENVIRONMENT in os.environ:
-        extension_dir = pathlib.Path(os.environ[EXTENSION_DIR_FROM_ENVIRONMENT])
-        extension_dir.absolute()
-        extension_file = extension_dir / filename
-
-    return json_file, extension_file
-
-
-def _load(json_file: pathlib.Path, extension_file: pathlib.Path):
-    with open(json_file, "r", encoding="utf-8") as file:
-        data = json.load(file)
-
-    if not extension_file or not extension_file.exists():
-        return data
-
-    with open(extension_file, "r", encoding="utf-8") as file:
-        extension_data = json.load(file)
-
-    top_level_sections = list(data.keys())
-    for key in top_level_sections:
-        if key not in extension_data:
-            continue
-
-        data[key].update(extension_data[key])
-
-    return data
+    return _factory
 
 
 #: In memory representation of the data in microarchitectures.json,
 #: loaded on first access
-TARGETS_JSON = LazyDictionary(_load, *_json_file("microarchitectures.json", allow_custom=True))
+TARGETS_JSON = LazyDictionary(_load_json_file("microarchitectures.json"))
 
 #: JSON schema for microarchitectures.json, loaded on first access
-TARGETS_JSON_SCHEMA = LazyDictionary(_load, *_json_file("microarchitectures_schema.json"))
-
-#: Information on how to call 'cpuid' to get information on the HOST CPU
-CPUID_JSON = LazyDictionary(_load, *_json_file("cpuid.json", allow_custom=True))
-
-#: JSON schema for cpuid.json, loaded on first access
-CPUID_JSON_SCHEMA = LazyDictionary(_load, *_json_file("cpuid_schema.json"))
+SCHEMA = LazyDictionary(_load_json_file("microarchitectures_schema.json"))

lib/spack/external/archspec/json/README.md

@@ -9,11 +9,11 @@ language specific APIs.
 
 Currently the repository contains the following JSON files:
 ```console
-cpu/
-├── cpuid.json                     # Contains information on CPUID calls to retrieve vendor and features on x86_64
-├── cpuid_schema.json              # Schema for the file above
-├── microarchitectures.json        # Contains information on CPU microarchitectures
-└── microarchitectures_schema.json # Schema for the file above
+.
+├── COPYRIGHT
+└── cpu
+    ├── microarchitectures.json         # Contains information on CPU microarchitectures
+    └── microarchitectures_schema.json  # Schema for the file above
  ```
 
 

lib/spack/external/archspec/json/cpu/cpuid_schema.json

@@ -1,134 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Schema for microarchitecture definitions and feature aliases",
-  "type": "object",
-  "additionalProperties": false,
-  "properties": {
-    "vendor": {
-      "type": "object",
-      "additionalProperties": false,
-      "properties": {
-        "description": {
-          "type": "string"
-        },
-        "input": {
-          "type": "object",
-          "additionalProperties": false,
-          "properties": {
-            "eax": {
-              "type": "integer"
-            },
-            "ecx": {
-              "type": "integer"
-            }
-          }
-        }
-      }
-    },
-    "highest_extension_support": {
-      "type": "object",
-      "additionalProperties": false,
-      "properties": {
-        "description": {
-          "type": "string"
-        },
-        "input": {
-          "type": "object",
-          "additionalProperties": false,
-          "properties": {
-            "eax": {
-              "type": "integer"
-            },
-            "ecx": {
-              "type": "integer"
-            }
-          }
-        }
-      }
-    },
-    "flags": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "additionalProperties": false,
-        "properties": {
-          "description": {
-            "type": "string"
-          },
-          "input": {
-            "type": "object",
-            "additionalProperties": false,
-            "properties": {
-              "eax": {
-                "type": "integer"
-              },
-              "ecx": {
-                "type": "integer"
-              }
-            }
-          },
-          "bits": {
-            "type": "array",
-            "items": {
-              "type": "object",
-              "additionalProperties": false,
-              "properties": {
-                "name": {
-                  "type": "string"
-                },
-                "register": {
-                  "type": "string"
-                },
-                "bit": {
-                  "type": "integer"
-                }
-              }
-            }
-          }
-        }
-      }
-    },
-    "extension-flags": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "additionalProperties": false,
-        "properties": {
-          "description": {
-            "type": "string"
-          },
-          "input": {
-            "type": "object",
-            "additionalProperties": false,
-            "properties": {
-              "eax": {
-                "type": "integer"
-              },
-              "ecx": {
-                "type": "integer"
-              }
-            }
-          },
-          "bits": {
-            "type": "array",
-            "items": {
-              "type": "object",
-              "additionalProperties": false,
-              "properties": {
-                "name": {
-                  "type": "string"
-                },
-                "register": {
-                  "type": "string"
-                },
-                "bit": {
-                  "type": "integer"
-                }
-              }
-            }
-          }
-        }
-      }
-    }
-  }
-}

lib/spack/external/archspec/json/cpu/microarchitectures.json

@@ -1482,6 +1482,7 @@
         "cldemote",
         "movdir64b",
         "movdiri",
+        "pdcm",
         "serialize",
         "waitpkg"
       ],
@@ -2224,96 +2225,14 @@
         ],
         "nvhpc": [
           {
-            "versions": "21.11:23.8",
+            "versions": "21.11:",
 	    "name": "zen3",
             "flags": "-tp {name}",
-	    "warnings": "zen4 is not fully supported by nvhpc versions < 23.9, falling back to zen3"
-          },
-          {
-            "versions": "23.9:",
-            "flags": "-tp {name}"
+	    "warnings": "zen4 is not fully supported by nvhpc yet, falling back to zen3"
           }
 	]
       }
     },
-    "zen5": {
-      "from": ["zen4"],
-      "vendor": "AuthenticAMD",
-      "features": [
-        "abm",
-        "aes",
-        "avx",
-        "avx2",
-        "avx512_bf16",
-        "avx512_bitalg",
-        "avx512bw",
-        "avx512cd",
-        "avx512dq",
-        "avx512f",
-        "avx512ifma",
-        "avx512vbmi",
-        "avx512_vbmi2",
-        "avx512vl",
-        "avx512_vnni",
-        "avx512_vp2intersect",
-        "avx512_vpopcntdq",
-        "avx_vnni",
-        "bmi1",
-        "bmi2",
-        "clflushopt",
-        "clwb",
-        "clzero",
-        "cppc",
-        "cx16",
-        "f16c",
-        "flush_l1d",
-        "fma",
-        "fsgsbase",
-        "gfni",
-        "ibrs_enhanced",
-        "mmx",
-        "movbe",
-        "movdir64b",
-        "movdiri",
-        "pclmulqdq",
-        "popcnt",
-        "rdseed",
-        "sse",
-        "sse2",
-        "sse4_1",
-        "sse4_2",
-        "sse4a",
-        "ssse3",
-        "tsc_adjust",
-        "vaes",
-        "vpclmulqdq",
-        "xsavec",
-        "xsaveopt"
-      ],
-      "compilers": {
-        "gcc": [
-          {
-            "versions": "14.1:",
-            "name": "znver5",
-            "flags": "-march={name} -mtune={name}"
-          }
-        ],
-        "aocc": [
-          {
-            "versions": "5.0:",
-            "name": "znver5",
-            "flags": "-march={name} -mtune={name}"
-          }
-        ],
-        "clang": [
-          {
-            "versions": "19.1:",
-            "name": "znver5",
-            "flags": "-march={name} -mtune={name}"
-          }
-        ]
-      }
-    },
     "ppc64": {
       "from": [],
       "vendor": "generic",
@@ -2792,8 +2711,7 @@
             "flags": "-mcpu=thunderx2t99"
           }
         ]
-      },
-      "cpupart": "0x0af"
+      }
     },
     "a64fx": {
       "from": ["armv8.2a"],
@@ -2861,8 +2779,7 @@
             "flags": "-march=armv8.2-a+crc+crypto+fp16+sve"
           }
         ]
-      },
-      "cpupart": "0x001"
+      }
     },
     "cortex_a72": {
       "from": ["aarch64"],
@@ -2899,8 +2816,7 @@
                   "flags" : "-mcpu=cortex-a72"
               }
           ]
-      },
-      "cpupart": "0xd08"
+      }
     },
     "neoverse_n1": {
       "from": ["cortex_a72", "armv8.2a"],
@@ -2921,7 +2837,8 @@
           "asimdrdm",
           "lrcpc",
           "dcpop",
-          "asimddp"
+          "asimddp",
+          "ssbs"
       ],
       "compilers" : {
           "gcc": [
@@ -2985,8 +2902,7 @@
                   "flags": "-tp {name}"
               }
           ]
-      },
-      "cpupart": "0xd0c"
+      }
     },
     "neoverse_v1": {
       "from": ["neoverse_n1", "armv8.4a"],
@@ -3010,6 +2926,8 @@
           "lrcpc",
           "dcpop",
           "sha3",
+          "sm3",
+          "sm4",
           "asimddp",
           "sha512",
           "sve",
@@ -3018,6 +2936,9 @@
           "uscat",
           "ilrcpc",
           "flagm",
+          "ssbs",
+          "paca",
+          "pacg",
           "dcpodp",
           "svei8mm",
           "svebf16",
@@ -3085,7 +3006,7 @@
               },
               {
                   "versions": "11:",
-                  "flags" : "-march=armv8.4-a+sve+fp16+bf16+crypto+i8mm+rng"
+                  "flags" : "-march=armv8.4-a+sve+ssbs+fp16+bf16+crypto+i8mm+rng"
               },
               {
                   "versions": "12:",
@@ -3109,8 +3030,7 @@
                   "flags": "-tp {name}"
               }
           ]
-      },
-      "cpupart": "0xd40"
+      }
     },
     "neoverse_v2": {
       "from": ["neoverse_n1", "armv9.0a"],
@@ -3134,22 +3054,35 @@
 	  "lrcpc",
 	  "dcpop",
 	  "sha3",
+	  "sm3",
+	  "sm4",
 	  "asimddp",
 	  "sha512",
 	  "sve",
 	  "asimdfhm",
+	  "dit",
 	  "uscat",
 	  "ilrcpc",
 	  "flagm",
+	  "ssbs",
 	  "sb",
+	  "paca",
+	  "pacg",
 	  "dcpodp",
 	  "sve2",
+	  "sveaes",
+	  "svepmull",
+	  "svebitperm",
+	  "svesha3",
+	  "svesm4",
 	  "flagm2",
 	  "frint",
 	  "svei8mm",
 	  "svebf16",
 	  "i8mm",
-	  "bf16"
+	  "bf16",
+	  "dgh",
+	  "bti"
       ],
       "compilers" : {
           "gcc": [
@@ -3174,19 +3107,15 @@
                   "flags" : "-march=armv8.5-a+sve -mtune=cortex-a76"
               },
               {
-                  "versions": "10.0:11.3.99",
+                  "versions": "10.0:11.99",
                   "flags" : "-march=armv8.5-a+sve+sve2+i8mm+bf16 -mtune=cortex-a77"
               },
-	      {
-                  "versions": "11.4:11.99",
-                  "flags" : "-mcpu=neoverse-v2"
-              },
               {
-                  "versions": "12.0:12.2.99",
+                  "versions": "12.0:12.99",
                   "flags" : "-march=armv9-a+i8mm+bf16 -mtune=cortex-a710"
               },
 	      {
-                  "versions": "12.3:",
+                  "versions": "13.0:",
                   "flags" : "-mcpu=neoverse-v2"
               }
           ],
@@ -3221,112 +3150,7 @@
                   "flags": "-tp {name}"
               }
           ]
-      },
-      "cpupart": "0xd4f"
-    },
-    "neoverse_n2": {
-      "from": ["neoverse_n1", "armv9.0a"],
-      "vendor": "ARM",
-      "features": [
-          "fp",
-	  "asimd",
-	  "evtstrm",
-	  "aes",
-	  "pmull",
-	  "sha1",
-	  "sha2",
-	  "crc32",
-	  "atomics",
-	  "fphp",
-	  "asimdhp",
-	  "cpuid",
-	  "asimdrdm",
-	  "jscvt",
-	  "fcma",
-	  "lrcpc",
-	  "dcpop",
-	  "sha3",
-	  "asimddp",
-	  "sha512",
-	  "sve",
-	  "asimdfhm",
-	  "uscat",
-	  "ilrcpc",
-	  "flagm",
-	  "sb",
-	  "dcpodp",
-	  "sve2",
-	  "flagm2",
-	  "frint",
-	  "svei8mm",
-	  "svebf16",
-	  "i8mm",
-	  "bf16"
-      ],
-      "compilers" : {
-          "gcc": [
-              {
-                  "versions": "4.8:5.99",
-                  "flags": "-march=armv8-a"
-              },
-              {
-                  "versions": "6:6.99",
-                  "flags" : "-march=armv8.1-a"
-              },
-              {
-                  "versions": "7.0:7.99",
-                  "flags" : "-march=armv8.2-a -mtune=cortex-a72"
-              },
-              {
-                  "versions": "8.0:8.99",
-                  "flags" : "-march=armv8.4-a+sve -mtune=cortex-a72"
-              },
-              {
-                  "versions": "9.0:9.99",
-                  "flags" : "-march=armv8.5-a+sve -mtune=cortex-a76"
-              },
-              {
-                  "versions": "10.0:10.99",
-                  "flags" : "-march=armv8.5-a+sve+sve2+i8mm+bf16 -mtune=cortex-a77"
-              },
-              {
-                  "versions": "11.0:",
-                  "flags" : "-mcpu=neoverse-n2"
-              }
-          ],
-          "clang" : [
-              {
-                  "versions": "9.0:10.99",
-                  "flags" : "-march=armv8.5-a+sve"
-              },
-              {
-                  "versions": "11.0:13.99",
-                  "flags" : "-march=armv8.5-a+sve+sve2+i8mm+bf16"
-              },
-              {
-                  "versions": "14.0:15.99",
-                  "flags" : "-march=armv9-a+i8mm+bf16"
-              },
-              {
-                  "versions": "16.0:",
-                  "flags" : "-mcpu=neoverse-n2"
-              }
-          ],
-          "arm" : [
-              {
-                  "versions": "23.04.0:",
-                  "flags" : "-mcpu=neoverse-n2"
-              }
-          ],
-          "nvhpc" : [
-              {
-                  "versions": "23.3:",
-                  "name": "neoverse-n1",
-                  "flags": "-tp {name}"
-              }
-          ]
-      },
-      "cpupart": "0xd49"
+      }
     },
     "m1": {
       "from": ["armv8.4a"],
@@ -3392,8 +3216,7 @@
             "flags" : "-mcpu=apple-m1"
           }
         ]
-      },
-      "cpupart": "0x022"
+      }
     },
     "m2": {
       "from": ["m1", "armv8.5a"],
@@ -3471,8 +3294,7 @@
             "flags" : "-mcpu=apple-m2"
           }
         ]
-      },
-      "cpupart": "0x032"
+      }
     },
     "arm": {
       "from": [],

lib/spack/external/archspec/json/cpu/microarchitectures_schema.json

@@ -52,9 +52,6 @@
                   }
                 }
               }
-            },
-            "cpupart": {
-              "type": "string"
             }
           },
           "required": [
@@ -110,4 +107,4 @@
       "additionalProperties": false
     }
   }
-}
+}

lib/spack/external/archspec/vendor/cpuid/LICENSE

@@ -1,20 +0,0 @@
-The MIT License (MIT)
-
-Copyright (c) 2014 Anders Høst
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

lib/spack/external/archspec/vendor/cpuid/README.md

@@ -1,76 +0,0 @@
-cpuid.py
-========
-
-Now, this is silly!
-
-Pure Python library for accessing information about x86 processors
-by querying the [CPUID](http://en.wikipedia.org/wiki/CPUID)
-instruction. Well, not exactly pure Python...
-
-It works by allocating a small piece of virtual memory, copying
-a raw x86 function to that memory, giving the memory execute
-permissions and then calling the memory as a function. The injected
-function executes the CPUID instruction and copies the result back
-to a ctypes.Structure where is can be read by Python.
-
-It should work fine on both 32 and 64 bit versions of Windows and Linux
-running x86 processors. Apple OS X and other BSD systems should also work,
-not tested though...
-
-
-Why?
-----
-For poops and giggles. Plus, having access to a low-level feature
-without having to compile a C wrapper is pretty neat.
-
-
-Examples
---------
-Getting info with eax=0:
-
-    import cpuid
-
-    q = cpuid.CPUID()
-    eax, ebx, ecx, edx = q(0)
-
-Running the files:
-
-    $ python example.py 
-    Vendor ID : GenuineIntel
-    CPU name  : Intel(R) Xeon(R) CPU           W3550  @ 3.07GHz
-    
-    Vector instructions supported:
-    SSE       : Yes
-    SSE2      : Yes
-    SSE3      : Yes
-    SSSE3     : Yes
-    SSE4.1    : Yes
-    SSE4.2    : Yes
-    SSE4a     : --
-    AVX       : --
-    AVX2      : --
-    
-    $ python cpuid.py
-    CPUID    A        B        C        D
-    00000000 0000000b 756e6547 6c65746e 49656e69
-    00000001 000106a5 00100800 009ce3bd bfebfbff
-    00000002 55035a01 00f0b2e4 00000000 09ca212c
-    00000003 00000000 00000000 00000000 00000000
-    00000004 00000000 00000000 00000000 00000000
-    00000005 00000040 00000040 00000003 00001120
-    00000006 00000003 00000002 00000001 00000000
-    00000007 00000000 00000000 00000000 00000000
-    00000008 00000000 00000000 00000000 00000000
-    00000009 00000000 00000000 00000000 00000000
-    0000000a 07300403 00000044 00000000 00000603
-    0000000b 00000000 00000000 00000095 00000000
-    80000000 80000008 00000000 00000000 00000000
-    80000001 00000000 00000000 00000001 28100800
-    80000002 65746e49 2952286c 6f655820 2952286e
-    80000003 55504320 20202020 20202020 57202020
-    80000004 30353533 20402020 37302e33 007a4847
-    80000005 00000000 00000000 00000000 00000000
-    80000006 00000000 00000000 01006040 00000000
-    80000007 00000000 00000000 00000000 00000100
-    80000008 00003024 00000000 00000000 00000000
-

lib/spack/external/archspec/vendor/cpuid/cpuid.py

@@ -1,172 +0,0 @@
-# -*- coding: utf-8 -*-
-#
-#     Copyright (c) 2024 Anders Høst
-#
-
-from __future__ import print_function
-
-import platform
-import os
-import ctypes
-from ctypes import c_uint32, c_long, c_ulong, c_size_t, c_void_p, POINTER, CFUNCTYPE
-
-# Posix x86_64:
-# Three first call registers : RDI, RSI, RDX
-# Volatile registers         : RAX, RCX, RDX, RSI, RDI, R8-11
-
-# Windows x86_64:
-# Three first call registers : RCX, RDX, R8
-# Volatile registers         : RAX, RCX, RDX, R8-11
-
-# cdecl 32 bit:
-# Three first call registers : Stack (%esp)
-# Volatile registers         : EAX, ECX, EDX
-
-_POSIX_64_OPC = [
-        0x53,                    # push   %rbx
-        0x89, 0xf0,              # mov    %esi,%eax
-        0x89, 0xd1,              # mov    %edx,%ecx
-        0x0f, 0xa2,              # cpuid
-        0x89, 0x07,              # mov    %eax,(%rdi)
-        0x89, 0x5f, 0x04,        # mov    %ebx,0x4(%rdi)
-        0x89, 0x4f, 0x08,        # mov    %ecx,0x8(%rdi)
-        0x89, 0x57, 0x0c,        # mov    %edx,0xc(%rdi)
-        0x5b,                    # pop    %rbx
-        0xc3                     # retq
-]
-
-_WINDOWS_64_OPC = [
-        0x53,                    # push   %rbx
-        0x89, 0xd0,              # mov    %edx,%eax
-        0x49, 0x89, 0xc9,        # mov    %rcx,%r9
-        0x44, 0x89, 0xc1,        # mov    %r8d,%ecx
-        0x0f, 0xa2,              # cpuid
-        0x41, 0x89, 0x01,        # mov    %eax,(%r9)
-        0x41, 0x89, 0x59, 0x04,  # mov    %ebx,0x4(%r9)
-        0x41, 0x89, 0x49, 0x08,  # mov    %ecx,0x8(%r9)
-        0x41, 0x89, 0x51, 0x0c,  # mov    %edx,0xc(%r9)
-        0x5b,                    # pop    %rbx
-        0xc3                     # retq
-]
-
-_CDECL_32_OPC = [
-        0x53,                    # push   %ebx
-        0x57,                    # push   %edi
-        0x8b, 0x7c, 0x24, 0x0c,  # mov    0xc(%esp),%edi
-        0x8b, 0x44, 0x24, 0x10,  # mov    0x10(%esp),%eax
-        0x8b, 0x4c, 0x24, 0x14,  # mov    0x14(%esp),%ecx
-        0x0f, 0xa2,              # cpuid
-        0x89, 0x07,              # mov    %eax,(%edi)
-        0x89, 0x5f, 0x04,        # mov    %ebx,0x4(%edi)
-        0x89, 0x4f, 0x08,        # mov    %ecx,0x8(%edi)
-        0x89, 0x57, 0x0c,        # mov    %edx,0xc(%edi)
-        0x5f,                    # pop    %edi
-        0x5b,                    # pop    %ebx
-        0xc3                     # ret
-]
-
-is_windows = os.name == "nt"
-is_64bit = ctypes.sizeof(ctypes.c_voidp) == 8
-
-
-class CPUID_struct(ctypes.Structure):
-    _register_names = ("eax", "ebx", "ecx", "edx")
-    _fields_ = [(r, c_uint32) for r in _register_names]
-
-    def __getitem__(self, item):
-        if item not in self._register_names:
-            raise KeyError(item)
-        return getattr(self, item)
-
-    def __repr__(self):
-        return "eax=0x{:x}, ebx=0x{:x}, ecx=0x{:x}, edx=0x{:x}".format(self.eax, self.ebx, self.ecx, self.edx)
-
-
-class CPUID(object):
-    def __init__(self):
-        if platform.machine() not in ("AMD64", "x86_64", "x86", "i686"):
-            raise SystemError("Only available for x86")
-
-        if is_windows:
-            if is_64bit:
-                # VirtualAlloc seems to fail under some weird
-                # circumstances when ctypes.windll.kernel32 is
-                # used under 64 bit Python. CDLL fixes this.
-                self.win = ctypes.CDLL("kernel32.dll")
-                opc = _WINDOWS_64_OPC
-            else:
-                # Here ctypes.windll.kernel32 is needed to get the
-                # right DLL. Otherwise it will fail when running
-                # 32 bit Python on 64 bit Windows.
-                self.win = ctypes.windll.kernel32
-                opc = _CDECL_32_OPC
-        else:
-            opc = _POSIX_64_OPC if is_64bit else _CDECL_32_OPC
-
-        size = len(opc)
-        code = (ctypes.c_ubyte * size)(*opc)
-
-        if is_windows:
-            self.win.VirtualAlloc.restype = c_void_p
-            self.win.VirtualAlloc.argtypes = [ctypes.c_void_p, ctypes.c_size_t, ctypes.c_ulong, ctypes.c_ulong]
-            self.addr = self.win.VirtualAlloc(None, size, 0x1000, 0x40)
-            if not self.addr:
-                raise MemoryError("Could not allocate RWX memory")
-            ctypes.memmove(self.addr, code, size)
-        else:
-            from mmap import (
-                mmap,
-                MAP_PRIVATE,
-                MAP_ANONYMOUS,
-                PROT_WRITE,
-                PROT_READ,
-                PROT_EXEC,
-            )
-            self.mm = mmap(
-                -1,
-                size,
-                flags=MAP_PRIVATE | MAP_ANONYMOUS,
-                prot=PROT_WRITE | PROT_READ | PROT_EXEC,
-            )
-            self.mm.write(code)
-            self.addr = ctypes.addressof(ctypes.c_int.from_buffer(self.mm))
-
-        func_type = CFUNCTYPE(None, POINTER(CPUID_struct), c_uint32, c_uint32)
-        self.func_ptr = func_type(self.addr)
-
-    def __call__(self, eax, ecx=0):
-        struct = self.registers_for(eax=eax, ecx=ecx)
-        return struct.eax, struct.ebx, struct.ecx, struct.edx
-
-    def registers_for(self, eax, ecx=0):
-        """Calls cpuid with eax and ecx set as the input arguments, and returns a structure
-        containing eax, ebx, ecx, and edx.
-        """
-        struct = CPUID_struct()
-        self.func_ptr(struct, eax, ecx)
-        return struct
-
-    def __del__(self):
-        if is_windows:
-            self.win.VirtualFree.restype = c_long
-            self.win.VirtualFree.argtypes = [c_void_p, c_size_t, c_ulong]
-            self.win.VirtualFree(self.addr, 0, 0x8000)
-        else:
-            self.mm.close()
-
-
-
-if __name__ == "__main__":
-    def valid_inputs():
-        cpuid = CPUID()
-        for eax in (0x0, 0x80000000):
-            highest, _, _, _ = cpuid(eax)
-            while eax <= highest:
-                regs = cpuid(eax)
-                yield (eax, regs)
-                eax += 1
-
-
-    print(" ".join(x.ljust(8) for x in ("CPUID", "A", "B", "C", "D")).strip())
-    for eax, regs in valid_inputs():
-        print("%08x" % eax, " ".join("%08x" % reg for reg in regs))

lib/spack/external/archspec/vendor/cpuid/example.py

@@ -1,62 +0,0 @@
-# -*- coding: utf-8 -*-
-#
-#     Copyright (c) 2024 Anders Høst
-#
-
-from __future__ import print_function
-
-import struct
-import cpuid
-
-
-def cpu_vendor(cpu):
-    _, b, c, d = cpu(0)
-    return struct.pack("III", b, d, c).decode("utf-8")
-
-
-def cpu_name(cpu):
-    name = "".join((struct.pack("IIII", *cpu(0x80000000 + i)).decode("utf-8")
-                    for i in range(2, 5)))
-
-    return name.split('\x00', 1)[0]
-
-
-def is_set(cpu, leaf, subleaf, reg_idx, bit):
-    """
-    @param {leaf} %eax
-    @param {sublead} %ecx, 0 in most cases
-    @param {reg_idx} idx of [%eax, %ebx, %ecx, %edx], 0-based
-    @param {bit} bit of reg selected by {reg_idx}, 0-based
-    """
-
-    regs = cpu(leaf, subleaf)
-
-    if (1 << bit) & regs[reg_idx]:
-        return "Yes"
-    else:
-        return "--"
-
-
-if __name__ == "__main__":
-    cpu = cpuid.CPUID()
-
-    print("Vendor ID : %s" % cpu_vendor(cpu))
-    print("CPU name  : %s" % cpu_name(cpu))
-    print()
-    print("Vector instructions supported:")
-    print("SSE       : %s" % is_set(cpu, 1, 0, 3, 25))
-    print("SSE2      : %s" % is_set(cpu, 1, 0, 3, 26))
-    print("SSE3      : %s" % is_set(cpu, 1, 0, 2, 0))
-    print("SSSE3     : %s" % is_set(cpu, 1, 0, 2, 9))
-    print("SSE4.1    : %s" % is_set(cpu, 1, 0, 2, 19))
-    print("SSE4.2    : %s" % is_set(cpu, 1, 0, 2, 20))
-    print("SSE4a     : %s" % is_set(cpu, 0x80000001, 0, 2, 6))
-    print("AVX       : %s" % is_set(cpu, 1, 0, 2, 28))
-    print("AVX2      : %s" % is_set(cpu, 7, 0, 1, 5))
-    print("BMI1      : %s" % is_set(cpu, 7, 0, 1, 3))
-    print("BMI2      : %s" % is_set(cpu, 7, 0, 1, 8))
-    # Intel RDT CMT/MBM
-    print("L3 Monitoring : %s" % is_set(cpu, 0xf, 0, 3, 1))
-    print("L3 Occupancy  : %s" % is_set(cpu, 0xf, 1, 3, 0))
-    print("L3 Total BW   : %s" % is_set(cpu, 0xf, 1, 3, 1))
-    print("L3 Local BW   : %s" % is_set(cpu, 0xf, 1, 3, 2))

lib/spack/external/patches/distro.patch

@@ -1,45 +0,0 @@
-diff --git a/lib/spack/external/_vendoring/distro/distro.py b/lib/spack/external/_vendoring/distro/distro.py
-index 89e1868047..50c3b18d4d 100644
---- a/lib/spack/external/_vendoring/distro/distro.py
-+++ b/lib/spack/external/_vendoring/distro/distro.py
-@@ -1265,27 +1265,29 @@ def _distro_release_info(self) -> Dict[str, str]:
-             match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename)
-         else:
-             try:
--                basenames = [
--                    basename
--                    for basename in os.listdir(self.etc_dir)
--                    if basename not in _DISTRO_RELEASE_IGNORE_BASENAMES
--                    and os.path.isfile(os.path.join(self.etc_dir, basename))
--                ]
-+                with os.scandir(self.etc_dir) as it:
-+                    etc_files = [
-+                        p.path for p in it
-+                        if p.is_file() and p.name not in _DISTRO_RELEASE_IGNORE_BASENAMES
-+                    ]
-                 # We sort for repeatability in cases where there are multiple
-                 # distro specific files; e.g. CentOS, Oracle, Enterprise all
-                 # containing `redhat-release` on top of their own.
--                basenames.sort()
-+                etc_files.sort()
-             except OSError:
-                 # This may occur when /etc is not readable but we can't be
-                 # sure about the *-release files. Check common entries of
-                 # /etc for information. If they turn out to not be there the
-                 # error is handled in `_parse_distro_release_file()`.
--                basenames = _DISTRO_RELEASE_BASENAMES
--            for basename in basenames:
--                match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename)
-+                etc_files = [
-+                    os.path.join(self.etc_dir, basename)
-+                    for basename in _DISTRO_RELEASE_BASENAMES
-+                ]
-+
-+            for filepath in etc_files:
-+                match = _DISTRO_RELEASE_BASENAME_PATTERN.match(os.path.basename(filepath))
-                 if match is None:
-                     continue
--                filepath = os.path.join(self.etc_dir, basename)
-                 distro_info = self._parse_distro_release_file(filepath)
-                 # The name is always present if the pattern matches.
-                 if "name" not in distro_info:

lib/spack/external/patches/jsonschema.patch

@@ -13,191 +13,3 @@ index 6b630cdfbb..1791fe7fbf 100644
 -__version__ = metadata.version("jsonschema")
 +
 +__version__ = "3.2.0"
-diff --git a/lib/spack/external/_vendoring/jsonschema/_format.py b/lib/spack/external/_vendoring/jsonschema/_format.py
-index 281a7cfcff..29061e3661 100644
---- a/lib/spack/external/_vendoring/jsonschema/_format.py
-+++ b/lib/spack/external/_vendoring/jsonschema/_format.py
-@@ -231,96 +231,6 @@ def is_host_name(instance):
-     return True
- 
- 
--try:
--    # The built-in `idna` codec only implements RFC 3890, so we go elsewhere.
--    import idna
--except ImportError:
--    pass
--else:
--    @_checks_drafts(draft7="idn-hostname", raises=idna.IDNAError)
--    def is_idn_host_name(instance):
--        if not isinstance(instance, str_types):
--            return True
--        idna.encode(instance)
--        return True
--
--
--try:
--    import rfc3987
--except ImportError:
--    try:
--        from rfc3986_validator import validate_rfc3986
--    except ImportError:
--        pass
--    else:
--        @_checks_drafts(name="uri")
--        def is_uri(instance):
--            if not isinstance(instance, str_types):
--                return True
--            return validate_rfc3986(instance, rule="URI")
--
--        @_checks_drafts(
--            draft6="uri-reference",
--            draft7="uri-reference",
--            raises=ValueError,
--        )
--        def is_uri_reference(instance):
--            if not isinstance(instance, str_types):
--                return True
--            return validate_rfc3986(instance, rule="URI_reference")
--
--else:
--    @_checks_drafts(draft7="iri", raises=ValueError)
--    def is_iri(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return rfc3987.parse(instance, rule="IRI")
--
--    @_checks_drafts(draft7="iri-reference", raises=ValueError)
--    def is_iri_reference(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return rfc3987.parse(instance, rule="IRI_reference")
--
--    @_checks_drafts(name="uri", raises=ValueError)
--    def is_uri(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return rfc3987.parse(instance, rule="URI")
--
--    @_checks_drafts(
--        draft6="uri-reference",
--        draft7="uri-reference",
--        raises=ValueError,
--    )
--    def is_uri_reference(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return rfc3987.parse(instance, rule="URI_reference")
--
--
--try:
--    from strict_rfc3339 import validate_rfc3339
--except ImportError:
--    try:
--        from rfc3339_validator import validate_rfc3339
--    except ImportError:
--        validate_rfc3339 = None
--
--if validate_rfc3339:
--    @_checks_drafts(name="date-time")
--    def is_datetime(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return validate_rfc3339(instance)
--
--    @_checks_drafts(draft7="time")
--    def is_time(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return is_datetime("1970-01-01T" + instance)
--
--
- @_checks_drafts(name="regex", raises=re.error)
- def is_regex(instance):
-     if not isinstance(instance, str_types):
-@@ -340,86 +250,3 @@ def is_draft3_time(instance):
-     if not isinstance(instance, str_types):
-         return True
-     return datetime.datetime.strptime(instance, "%H:%M:%S")
--
--
--try:
--    import webcolors
--except ImportError:
--    pass
--else:
--    def is_css_color_code(instance):
--        return webcolors.normalize_hex(instance)
--
--    @_checks_drafts(draft3="color", raises=(ValueError, TypeError))
--    def is_css21_color(instance):
--        if (
--            not isinstance(instance, str_types) or
--            instance.lower() in webcolors.css21_names_to_hex
--        ):
--            return True
--        return is_css_color_code(instance)
--
--    def is_css3_color(instance):
--        if instance.lower() in webcolors.css3_names_to_hex:
--            return True
--        return is_css_color_code(instance)
--
--
--try:
--    import jsonpointer
--except ImportError:
--    pass
--else:
--    @_checks_drafts(
--        draft6="json-pointer",
--        draft7="json-pointer",
--        raises=jsonpointer.JsonPointerException,
--    )
--    def is_json_pointer(instance):
--        if not isinstance(instance, str_types):
--            return True
--        return jsonpointer.JsonPointer(instance)
--
--    # TODO: I don't want to maintain this, so it
--    #       needs to go either into jsonpointer (pending
--    #       https://github.com/stefankoegl/python-json-pointer/issues/34) or
--    #       into a new external library.
--    @_checks_drafts(
--        draft7="relative-json-pointer",
--        raises=jsonpointer.JsonPointerException,
--    )
--    def is_relative_json_pointer(instance):
--        # Definition taken from:
--        # https://tools.ietf.org/html/draft-handrews-relative-json-pointer-01#section-3
--        if not isinstance(instance, str_types):
--            return True
--        non_negative_integer, rest = [], ""
--        for i, character in enumerate(instance):
--            if character.isdigit():
--                non_negative_integer.append(character)
--                continue
--
--            if not non_negative_integer:
--                return False
--
--            rest = instance[i:]
--            break
--        return (rest == "#") or jsonpointer.JsonPointer(rest)
--
--
--try:
--    import uritemplate.exceptions
--except ImportError:
--    pass
--else:
--    @_checks_drafts(
--        draft6="uri-template",
--        draft7="uri-template",
--        raises=uritemplate.exceptions.InvalidTemplate,
--    )
--    def is_uri_template(
--        instance,
--        template_validator=uritemplate.Validator().force_balanced_braces(),
--    ):
--        template = uritemplate.URITemplate(instance)
--        return template_validator.validate(template)

lib/spack/external/patches/ruamelyaml.patch

@@ -1,13 +0,0 @@
-diff --git a/lib/spack/external/_vendoring/ruamel/yaml/comments.py b/lib/spack/external/_vendoring/ruamel/yaml/comments.py
-index 1badeda585..892c868af3 100644
---- a/lib/spack/external/_vendoring/ruamel/yaml/comments.py
-+++ b/lib/spack/external/_vendoring/ruamel/yaml/comments.py
-@@ -497,7 +497,7 @@ def copy_attributes(self, t, memo=None):
-                   Tag.attrib, merge_attrib]:
-             if hasattr(self, a):
-                 if memo is not None:
--                    setattr(t, a, copy.deepcopy(getattr(self, a, memo)))
-+                    setattr(t, a, copy.deepcopy(getattr(self, a), memo))
-                 else:
-                     setattr(t, a, getattr(self, a))
-         # fmt: on

lib/spack/llnl/path.py

@@ -42,6 +42,11 @@ def convert_to_posix_path(path: str) -> str:
     return format_os_path(path, mode=Path.unix)
 
 
+def convert_to_windows_path(path: str) -> str:
+    """Converts the input path to Windows style."""
+    return format_os_path(path, mode=Path.windows)
+
+
 def convert_to_platform_path(path: str) -> str:
     """Converts the input path to the current platform's native style."""
     return format_os_path(path, mode=Path.platform_path)
@@ -98,10 +103,3 @@ def path_filter_caller(*args, **kwargs):
     if _func:
         return holder_func(_func)
     return holder_func
-
-
-def sanitize_win_longpath(path: str) -> str:
-    """Strip Windows extended path prefix from strings
-    Returns sanitized string.
-    no-op if extended path prefix is not present"""
-    return path.lstrip("\\\\?\\")

lib/spack/llnl/string.py

@@ -41,20 +41,6 @@ def comma_and(sequence: List[str]) -> str:
     return comma_list(sequence, "and")
 
 
-def ordinal(number: int) -> str:
-    """Return the ordinal representation (1st, 2nd, 3rd, etc.) for the provided number.
-
-    Args:
-        number: int to convert to ordinal number
-
-    Returns: number's corresponding ordinal
-    """
-    idx = (number % 10) << 1
-    tens = number % 100 // 10
-    suffix = "th" if tens == 1 or idx > 6 else "thstndrd"[idx : idx + 2]
-    return f"{number}{suffix}"
-
-
 def quote(sequence: List[str], q: str = "'") -> List[str]:
     """Quotes each item in the input list with the quote character passed as second argument."""
     return [f"{q}{e}{q}" for e in sequence]

lib/spack/llnl/url.py

@@ -12,7 +12,7 @@
 # Archive extensions allowed in Spack
 PREFIX_EXTENSIONS = ("tar", "TAR")
 EXTENSIONS = ("gz", "bz2", "xz", "Z")
-NO_TAR_EXTENSIONS = ("zip", "tgz", "tbz2", "tbz", "txz", "whl")
+NO_TAR_EXTENSIONS = ("zip", "tgz", "tbz2", "tbz", "txz")
 
 # Add PREFIX_EXTENSIONS and EXTENSIONS last so that .tar.gz is matched *before* .tar or .gz
 ALLOWED_ARCHIVE_TYPES = (
@@ -357,8 +357,10 @@ def strip_version_suffixes(path_or_url: str) -> str:
         r"i[36]86",
         r"ppc64(le)?",
         r"armv?(7l|6l|64)?",
-        # PyPI wheels
-        r"-(?:py|cp)[23].*",
+        # PyPI
+        r"[._-]py[23].*\.whl",
+        r"[._-]cp[23].*\.whl",
+        r"[._-]win.*\.exe",
     ]
 
     for regex in suffix_regexes:
@@ -401,7 +403,7 @@ def expand_contracted_extension_in_path(
 def compression_ext_from_compressed_archive(extension: str) -> Optional[str]:
     """Returns compression extension for a compressed archive"""
     extension = expand_contracted_extension(extension)
-    for ext in EXTENSIONS:
+    for ext in [*EXTENSIONS]:
         if ext in extension:
             return ext
     return None

lib/spack/llnl/util/lang.py

@@ -5,20 +5,18 @@
 
 import collections.abc
 import contextlib
-import fnmatch
 import functools
+import inspect
 import itertools
 import os
 import re
 import sys
 import traceback
-import typing
-import warnings
 from datetime import datetime, timedelta
-from typing import Callable, Dict, Iterable, List, Tuple, TypeVar
+from typing import Any, Callable, Iterable, List, Tuple
 
 # Ignore emacs backups when listing modules
-ignore_modules = r"^\.#|~$"
+ignore_modules = [r"^\.#", "~$"]
 
 
 def index_by(objects, *funcs):
@@ -86,6 +84,50 @@ def index_by(objects, *funcs):
     return result
 
 
+def caller_locals():
+    """This will return the locals of the *parent* of the caller.
+    This allows a function to insert variables into its caller's
+    scope.  Yes, this is some black magic, and yes it's useful
+    for implementing things like depends_on and provides.
+    """
+    # Passing zero here skips line context for speed.
+    stack = inspect.stack(0)
+    try:
+        return stack[2][0].f_locals
+    finally:
+        del stack
+
+
+def get_calling_module_name():
+    """Make sure that the caller is a class definition, and return the
+    enclosing module's name.
+    """
+    # Passing zero here skips line context for speed.
+    stack = inspect.stack(0)
+    try:
+        # Make sure locals contain __module__
+        caller_locals = stack[2][0].f_locals
+    finally:
+        del stack
+
+    if "__module__" not in caller_locals:
+        raise RuntimeError(
+            "Must invoke get_calling_module_name() " "from inside a class definition!"
+        )
+
+    module_name = caller_locals["__module__"]
+    base_name = module_name.split(".")[-1]
+    return base_name
+
+
+def attr_required(obj, attr_name):
+    """Ensure that a class has a required attribute."""
+    if not hasattr(obj, attr_name):
+        raise RequiredAttributeError(
+            "No required attribute '%s' in class '%s'" % (attr_name, obj.__class__.__name__)
+        )
+
+
 def attr_setdefault(obj, name, value):
     """Like dict.setdefault, but for objects."""
     if not hasattr(obj, name):
@@ -93,6 +135,15 @@ def attr_setdefault(obj, name, value):
     return getattr(obj, name)
 
 
+def has_method(cls, name):
+    for base in inspect.getmro(cls):
+        if base is object:
+            continue
+        if name in base.__dict__:
+            return True
+    return False
+
+
 def union_dicts(*dicts):
     """Use update() to combine all dicts into one.
 
@@ -157,22 +208,19 @@ def list_modules(directory, **kwargs):
     order."""
     list_directories = kwargs.setdefault("directories", True)
 
-    ignore = re.compile(ignore_modules)
+    for name in os.listdir(directory):
+        if name == "__init__.py":
+            continue
 
-    with os.scandir(directory) as it:
-        for entry in it:
-            if entry.name == "__init__.py" or entry.name == "__pycache__":
-                continue
+        path = os.path.join(directory, name)
+        if list_directories and os.path.isdir(path):
+            init_py = os.path.join(path, "__init__.py")
+            if os.path.isfile(init_py):
+                yield name
 
-            if (
-                list_directories
-                and entry.is_dir()
-                and os.path.isfile(os.path.join(entry.path, "__init__.py"))
-            ):
-                yield entry.name
-
-            elif entry.name.endswith(".py") and entry.is_file() and not ignore.search(entry.name):
-                yield entry.name[:-3]  # strip .py
+        elif name.endswith(".py"):
+            if not any(re.search(pattern, name) for pattern in ignore_modules):
+                yield re.sub(".py$", "", name)
 
 
 def decorator_with_or_without_args(decorator):
@@ -219,8 +267,8 @@ def setter(name, value):
         value.__name__ = name
         setattr(cls, name, value)
 
-    if not hasattr(cls, "_cmp_key"):
-        raise TypeError(f"'{cls.__name__}' doesn't define _cmp_key().")
+    if not has_method(cls, "_cmp_key"):
+        raise TypeError("'%s' doesn't define _cmp_key()." % cls.__name__)
 
     setter("__eq__", lambda s, o: (s is o) or (o is not None and s._cmp_key() == o._cmp_key()))
     setter("__lt__", lambda s, o: o is not None and s._cmp_key() < o._cmp_key())
@@ -370,8 +418,8 @@ def cd_fun():
         TypeError: If the class does not have a ``_cmp_iter`` method
 
     """
-    if not hasattr(cls, "_cmp_iter"):
-        raise TypeError(f"'{cls.__name__}' doesn't define _cmp_iter().")
+    if not has_method(cls, "_cmp_iter"):
+        raise TypeError("'%s' doesn't define _cmp_iter()." % cls.__name__)
 
     # comparison operators are implemented in terms of lazy_eq and lazy_lt
     def eq(self, other):
@@ -465,6 +513,42 @@ def copy(self):
         return clone
 
 
+def in_function(function_name):
+    """True if the caller was called from some function with
+    the supplied Name, False otherwise."""
+    stack = inspect.stack()
+    try:
+        for elt in stack[2:]:
+            if elt[3] == function_name:
+                return True
+        return False
+    finally:
+        del stack
+
+
+def check_kwargs(kwargs, fun):
+    """Helper for making functions with kwargs.  Checks whether the kwargs
+    are empty after all of them have been popped off.  If they're
+    not, raises an error describing which kwargs are invalid.
+
+    Example::
+
+       def foo(self, **kwargs):
+           x = kwargs.pop('x', None)
+           y = kwargs.pop('y', None)
+           z = kwargs.pop('z', None)
+           check_kwargs(kwargs, self.foo)
+
+       # This raises a TypeError:
+       foo(w='bad kwarg')
+    """
+    if kwargs:
+        raise TypeError(
+            "'%s' is an invalid keyword argument for function %s()."
+            % (next(iter(kwargs)), fun.__name__)
+        )
+
+
 def match_predicate(*args):
     """Utility function for making string matching predicates.
 
@@ -680,6 +764,11 @@ def pretty_seconds(seconds):
     return pretty_seconds_formatter(seconds)(seconds)
 
 
+class RequiredAttributeError(ValueError):
+    def __init__(self, message):
+        super().__init__(message)
+
+
 class ObjectWrapper:
     """Base class that wraps an object. Derived classes can add new behavior
     while staying undercover.
@@ -754,30 +843,6 @@ def __repr__(self):
         return repr(self.instance)
 
 
-def get_entry_points(*, group: str):
-    """Wrapper for ``importlib.metadata.entry_points``
-
-    Args:
-        group: entry points to select
-
-    Returns:
-        EntryPoints for ``group`` or empty list if unsupported
-    """
-
-    try:
-        import importlib.metadata  # type: ignore  # novermin
-    except ImportError:
-        return []
-
-    try:
-        return importlib.metadata.entry_points(group=group)
-    except TypeError:
-        # Prior to Python 3.10, entry_points accepted no parameters and always
-        # returned a dictionary of entry points, keyed by group.  See
-        # https://docs.python.org/3/library/importlib.metadata.html#entry-points
-        return importlib.metadata.entry_points().get(group, [])
-
-
 def load_module_from_file(module_name, module_path):
     """Loads a python module from the path of the corresponding file.
 
@@ -846,32 +911,39 @@ def uniq(sequence):
     return uniq_list
 
 
-def elide_list(line_list: List[str], max_num: int = 10) -> List[str]:
+def star(func):
+    """Unpacks arguments for use with Multiprocessing mapping functions"""
+
+    def _wrapper(args):
+        return func(*args)
+
+    return _wrapper
+
+
+class Devnull:
+    """Null stream with less overhead than ``os.devnull``.
+
+    See https://stackoverflow.com/a/2929954.
+    """
+
+    def write(self, *_):
+        pass
+
+
+def elide_list(line_list, max_num=10):
     """Takes a long list and limits it to a smaller number of elements,
     replacing intervening elements with '...'.  For example::
 
-        elide_list(["1", "2", "3", "4", "5", "6"], 4)
+        elide_list([1,2,3,4,5,6], 4)
 
     gives::
 
-        ["1", "2", "3", "...", "6"]
+        [1, 2, 3, '...', 6]
     """
     if len(line_list) > max_num:
-        return [*line_list[: max_num - 1], "...", line_list[-1]]
-    return line_list
-
-
-if sys.version_info >= (3, 9):
-    PatternStr = re.Pattern[str]
-else:
-    PatternStr = typing.Pattern[str]
-
-
-def fnmatch_translate_multiple(named_patterns: Dict[str, str]) -> str:
-    """Similar to ``fnmatch.translate``, but takes an ordered dictionary where keys are pattern
-    names, and values are filename patterns. The output is a regex that matches any of the
-    patterns in order, and named capture groups are used to identify which pattern matched."""
-    return "|".join(f"(?P<{n}>{fnmatch.translate(p)})" for n, p in named_patterns.items())
+        return line_list[: max_num - 1] + ["..."] + line_list[-1:]
+    else:
+        return line_list
 
 
 @contextlib.contextmanager
@@ -886,12 +958,18 @@ class UnhashableArguments(TypeError):
     """Raise when an @memoized function receives unhashable arg or kwarg values."""
 
 
-T = TypeVar("T")
+def enum(**kwargs):
+    """Return an enum-like class.
+
+    Args:
+        **kwargs: explicit dictionary of enums
+    """
+    return type("Enum", (object,), kwargs)
 
 
 def stable_partition(
-    input_iterable: Iterable[T], predicate_fn: Callable[[T], bool]
-) -> Tuple[List[T], List[T]]:
+    input_iterable: Iterable, predicate_fn: Callable[[Any], bool]
+) -> Tuple[List[Any], List[Any]]:
     """Partition the input iterable according to a custom predicate.
 
     Args:
@@ -903,13 +981,12 @@ def stable_partition(
         Tuple of the list of elements evaluating to True, and
         list of elements evaluating to False.
     """
-    true_items: List[T] = []
-    false_items: List[T] = []
+    true_items, false_items = [], []
     for item in input_iterable:
         if predicate_fn(item):
             true_items.append(item)
-        else:
-            false_items.append(item)
+            continue
+        false_items.append(item)
     return true_items, false_items
 
 
@@ -921,21 +998,6 @@ def ensure_last(lst, *elements):
         lst.append(lst.pop(lst.index(elt)))
 
 
-class Const:
-    """Class level constant, raises when trying to set the attribute"""
-
-    __slots__ = ["value"]
-
-    def __init__(self, value):
-        self.value = value
-
-    def __get__(self, instance, owner):
-        return self.value
-
-    def __set__(self, instance, value):
-        raise TypeError(f"Const value does not support assignment [value={self.value}]")
-
-
 class TypedMutableSequence(collections.abc.MutableSequence):
     """Base class that behaves like a list, just with a different type.
 
@@ -1040,42 +1102,3 @@ def __init__(self, callback):
 
     def __get__(self, instance, owner):
         return self.callback(owner)
-
-
-class DeprecatedProperty:
-    """Data descriptor to error or warn when a deprecated property is accessed.
-
-    Derived classes must define a factory method to return an adaptor for the deprecated
-    property, if the descriptor is not set to error.
-    """
-
-    __slots__ = ["name"]
-
-    #: 0 - Nothing
-    #: 1 - Warning
-    #: 2 - Error
-    error_lvl = 0
-
-    def __init__(self, name: str) -> None:
-        self.name = name
-
-    def __get__(self, instance, owner):
-        if instance is None:
-            return self
-
-        if self.error_lvl == 1:
-            warnings.warn(
-                f"accessing the '{self.name}' property of '{instance}', which is deprecated"
-            )
-        elif self.error_lvl == 2:
-            raise AttributeError(f"cannot access the '{self.name}' attribute of '{instance}'")
-
-        return self.factory(instance, owner)
-
-    def __set__(self, instance, value):
-        raise TypeError(
-            f"the deprecated property '{self.name}' of '{instance}' does not support assignment"
-        )
-
-    def factory(self, instance, owner):
-        raise NotImplementedError("must be implemented by derived classes")