Set __version__ to v0.20.2

Currently buildcaches are forward incompatible in an annoying way: spack
errors out when trying to use them.

With this change, you just get a warning.

.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"
-}

.gitattributes

@@ -1,3 +1,4 @@
 *.py diff=python
+*.lp linguist-language=Prolog
 lib/spack/external/* linguist-vendored
-*.bat text eol=crlf
+*.bat text eol=crlf

.github/dependabot.yml

@@ -5,10 +5,8 @@ updates:
     directory: "/"
     schedule:
       interval: "daily"
-  # Requirements to run style checks and build documentation
+  # Requirements to build documentation
   - package-ecosystem: "pip"
-    directories:
+    directory: "/lib/spack/docs"
-     - "/.github/workflows/requirements/style/*"
-     - "/lib/spack/docs"
     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,57 +17,28 @@ concurrency:
 jobs:
   # Run audits on all the packages in the built-in repository
   package-audits:
-    runs-on: ${{ matrix.system.os }}
+    runs-on: ubuntu-latest
-    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 }}
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @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:
+      if: ${{ inputs.with_coverage == 'true' }}
-          COVERAGE_FILE: coverage/.coverage-audits-${{ matrix.system.os }}
-      if: ${{ inputs.with_coverage == 'true' && runner.os != 'Windows' }}
       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 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
+          $(which spack) audit packages
-          spack -d audit configs
+    - uses: codecov/codecov-action@894ff025c7b54547a9a2a1e9f228beae737ad3c2 # @v2.1.0
-          spack -d audit externals
+      if: ${{ inputs.with_coverage == 'true' }}
-    - name: Package audits (without coverage)
-      if: ${{ runner.os == 'Windows' }}
-      run: |
-          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@6f51ac03b9356f520e9adb1b1b7802705f340c2b
-      if: ${{ inputs.with_coverage == 'true' && runner.os != 'Windows' }}
       with:
-        name: coverage-audits-${{ matrix.system.os }}
+        flags: unittests,linux,audits
-        path: coverage
-        include-hidden-files: true

.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 }}
+    container: "fedora:latest"
-    strategy:
-      matrix:
-        image: ["fedora:latest", "opensuse/leap:latest"]
     steps:
-      - name: Setup Fedora
+      - name: Install dependencies
-        if: ${{ matrix.image == 'fedora:latest' }}
         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 gawk
+              cmake bison bison-devel libstdc++-static
-      - name: Setup OpenSUSE
+      - name: Checkout
-        if: ${{ matrix.image == 'opensuse/leap:latest' }}
+        uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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.4
+          spack bootstrap disable github-actions-v0.3
+          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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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.4
+          spack bootstrap disable github-actions-v0.3
+          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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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,98 @@ jobs:
               make patch unzip which xz python3 python3-devel tree \
               cmake bison
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
         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.4
-          spack bootstrap disable github-actions-v0.5
+          spack bootstrap disable github-actions-v0.3
           spack external find cmake bison
           spack -d solve zlib
           tree ~/.spack/bootstrap/store/
 
-  clingo-sources:
+  macos-clingo-sources:
-    runs-on: ${{ matrix.runner }}
+    runs-on: macos-latest
-    strategy:
-      matrix:
-        runner: ['macos-13', 'macos-14', "ubuntu-latest"]
     steps:
-      - name: Setup macOS
+      - name: Install dependencies
-        if: ${{ matrix.runner != 'ubuntu-latest' }}
         run: |
-          brew install cmake bison tree
+          brew install cmake bison@2.7 tree
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-        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 bootstrap disable github-actions-v0.3
           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:
+  macos-clingo-binaries:
-    runs-on: ${{ matrix.runner }}
+    runs-on: ${{ matrix.macos-version }}
     strategy:
       matrix:
-        runner: ['macos-13', 'macos-14', "ubuntu-latest"]
+        macos-version: ['macos-11', 'macos-12']
     steps:
-      - name: Setup macOS
+      - name: Install dependencies
-        if: ${{ matrix.runner != 'ubuntu-latest' }}
-        run: brew install tree
-      - name: Remove system executables
         run: |
-          while [ -n "$(command -v gpg gpg2 patchelf)" ]; do
+          brew install tree
-            sudo rm $(command -v gpg gpg2 patchelf)
-          done
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
-        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
       - name: Bootstrap clingo
         run: |
-          set -e
+          set -ex
-          for ver in '3.8' '3.9' '3.10' '3.11' '3.12' '3.13'; do
+          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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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,39 +233,120 @@ jobs:
               exit 1
             fi
           done
+
+  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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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 GnuPG
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+        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 GnuPG
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack solve zlib
+          spack bootstrap disable github-actions-v0.4
+          spack bootstrap disable github-actions-v0.3
+          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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
       - name: Bootstrap GnuPG
         run: |
           source share/spack/setup-env.sh
+          spack bootstrap disable spack-install
           spack -d gpg list
-          tree $HOME/.spack/bootstrap/store/
+          tree ~/.spack/bootstrap/store/
 
-
+  macos-gnupg-sources:
-  windows:
+    runs-on: macos-latest
-    runs-on: "windows-latest"
     steps:
+      - name: Install dependencies
+        run: |
+          brew install gawk tree
+          # Remove GnuPG since we want to bootstrap it
+          sudo rm -rf /usr/local/bin/gpg
       - name: Checkout
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+        uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-        with:
-          python-version: "3.12"
-      - name: Setup Windows
-        run: |
-          Remove-Item -Path (Get-Command gpg).Path
-          Remove-Item -Path (Get-Command file).Path
-      - name: Bootstrap clingo
-        run: |
-          ./share/spack/setup-env.ps1
-          spack bootstrap disable github-actions-v0.6
-          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/
       - name: Bootstrap GnuPG
         run: |
-          ./share/spack/setup-env.ps1
+          source share/spack/setup-env.sh
+          spack solve zlib
+          spack bootstrap disable github-actions-v0.4
+          spack bootstrap disable github-actions-v0.3
           spack -d gpg list
-          ./share/spack/qa/validate_last_exit.ps1
+          tree ~/.spack/bootstrap/store/
-          tree $env:userprofile/.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

@@ -38,52 +38,44 @@ jobs:
         # Meaning of the various items in the matrix list
         # 0: Container name (e.g. ubuntu-bionic)
         # 1: Platforms to build for
-        # 2: Base image (e.g. ubuntu:22.04)
+        # 2: Base image (e.g. ubuntu:18.04)
         dockerfile: [[amazon-linux, 'linux/amd64,linux/arm64', 'amazonlinux:2'],
-                     [centos-stream9, 'linux/amd64,linux/arm64', 'centos:stream9'],
+                     [centos7, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:7'],
-                     [leap15, 'linux/amd64,linux/arm64', 'opensuse/leap:15'],
+                     [centos-stream, 'linux/amd64,linux/arm64,linux/ppc64le', 'centos:stream'],
-                     [ubuntu-focal, 'linux/amd64,linux/arm64', 'ubuntu:20.04'],
+                     [leap15, 'linux/amd64,linux/arm64,linux/ppc64le', 'opensuse/leap:15'],
-                     [ubuntu-jammy, 'linux/amd64,linux/arm64', 'ubuntu:22.04'],
+                     [ubuntu-bionic, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:18.04'],
-                     [ubuntu-noble, 'linux/amd64,linux/arm64', 'ubuntu:24.04'],
+                     [ubuntu-focal, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:20.04'],
-                     [almalinux8, 'linux/amd64,linux/arm64', 'almalinux:8'],
+                     [ubuntu-jammy, 'linux/amd64,linux/arm64,linux/ppc64le', 'ubuntu:22.04'],
-                     [almalinux9, 'linux/amd64,linux/arm64', 'almalinux:9'],
+                     [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'],
+                     [rockylinux9, 'linux/amd64,linux/arm64,linux/ppc64le', 'rockylinux:9'],
-                     [fedora39, 'linux/amd64,linux/arm64', 'fedora:39'],
+                     [fedora37, 'linux/amd64,linux/arm64,linux/ppc64le', 'fedora:37'],
-                     [fedora40, 'linux/amd64,linux/arm64', 'fedora:40']]
+                     [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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
 
-      - name: Determine latest release tag
+      - name: Set Container Tag Normal (Nightly)
-        id: latest
         run: |
-          git fetch --quiet --tags
+          container="${{ matrix.dockerfile[0] }}:latest"
-          echo "tag=$(git tag --list --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1)" | tee -a $GITHUB_OUTPUT
+          echo "container=${container}" >> $GITHUB_ENV
+          echo "versioned=${container}" >> $GITHUB_ENV
 
-      - uses: docker/metadata-action@369eb591f429131d6889c46b94e711f089e6ca96
+        # On a new release create a container with the same tag as the release.
-        id: docker_meta
+      - name: Set Container Tag on Release
-        with:
+        if: github.event_name == 'release'
-          images: |
+        run: |
-              ghcr.io/${{ github.repository_owner }}/${{ matrix.dockerfile[0] }}
+          versioned="${{matrix.dockerfile[0]}}:${GITHUB_REF##*/}"
-              ${{ github.repository_owner }}/${{ matrix.dockerfile[0] }}
+          echo "versioned=${versioned}" >> $GITHUB_ENV
-          tags: |
-              type=schedule,pattern=nightly
-              type=schedule,pattern=develop
-              type=semver,pattern={{version}}
-              type=semver,pattern={{major}}.{{minor}}
-              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 +86,19 @@ jobs:
           fi
 
       - name: Upload Dockerfile
-        uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b1b7802705f340c2b
+        uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce
         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@e81a89b1732b9c48d79cd809d8d81d79c4647a18 # @v1
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@6524bf65af31da8d45b59e8c27de4bd072b392f5
+        uses: docker/setup-buildx-action@4b4e9c3e2d4531116a6f8ba8e71fc6e2cb6e6c8c # @v1
 
       - name: Log in to GitHub Container Registry
-        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567
+        uses: docker/login-action@f4ef78c080cd8ba55a85445d5b36e214a81df20a # @v1
         with:
           registry: ghcr.io
           username: ${{ github.actor }}
@@ -114,27 +106,21 @@ jobs:
 
       - name: Log in to DockerHub
         if: github.event_name != 'pull_request'
-        uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567
+        uses: docker/login-action@f4ef78c080cd8ba55a85445d5b36e214a81df20a # @v1
         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@3b5e8027fcad23fda98b2e3ac259d8d67585f671 # @v2
         with:
           context: dockerfiles/${{ matrix.dockerfile[0] }}
           platforms: ${{ matrix.dockerfile[1] }}
           push: ${{ github.event_name != 'pull_request' }}
-          tags: ${{ steps.docker_meta.outputs.tags }}
+          cache-from: type=gha
-          labels: ${{ steps.docker_meta.outputs.labels }}
+          cache-to: type=gha,mode=max
-
+          tags: |
-  merge-dockerfiles:
+            spack/${{ env.container }}
-    runs-on: ubuntu-latest
+            spack/${{ env.versioned }}
-    needs: deploy-images
+            ghcr.io/spack/${{ env.container }}
-    steps:
+            ghcr.io/spack/${{ env.versioned }}
-      - name: Merge Artifacts
-        uses: actions/upload-artifact/merge@6f51ac03b9356f520e9adb1b1b7802705f340c2b
-        with:
-          name: dockerfiles
-          pattern: dockerfiles_*
-          delete-merged: true

.github/workflows/ci.yaml

@@ -9,13 +9,23 @@ on:
     branches:
       - develop
       - releases/**
-  merge_group:
 
 concurrency:
   group: ci-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
   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
@@ -25,18 +35,14 @@ jobs:
       core: ${{ steps.filter.outputs.core }}
       packages: ${{ steps.filter.outputs.packages }}
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
-        if: ${{ github.event_name == 'push' || github.event_name == 'merge_group' }}
+        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:
-          # For merge group events, compare against the target branch (main)
-          base: ${{ github.event_name == 'merge_group' && github.event.merge_group.base_ref || '' }}
-          # For merge group events, use the merge group head ref
-          ref: ${{ github.event_name == 'merge_group' && github.event.merge_group.head_sha || github.ref }}
           # See https://github.com/dorny/paths-filter/issues/56 for the syntax used below
           # Don't run if we only modified packages in the
           # built-in repository or documentation
@@ -46,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'
@@ -71,60 +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
+  windows:
-
+    if: ${{ github.repository == 'spack/spack' && needs.changes.outputs.core == 'true' }}
-  prechecks:
-    needs: [ changes ]
-    uses: ./.github/workflows/prechecks.yml
-    secrets: inherit
-    with:
-      with_coverage: ${{ needs.changes.outputs.core }}
-      with_packages: ${{ needs.changes.outputs.packages }}
-
-  import-check:
-    needs: [ changes ]
-    uses: ./.github/workflows/import-check.yaml
-
-  all-prechecks:
     needs: [ prechecks ]
-    if: ${{ always() }}
+    uses: ./.github/workflows/windows_python.yml
+  all:
+    needs: [ windows, unit-tests, bootstrap ]
     runs-on: ubuntu-latest
     steps:
     - name: Success
-      run: |
+      run: "true"
-        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 ]
-    if: ${{ needs.changes.outputs.core }}
-    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

.github/workflows/coverage.yml

@@ -1,36 +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@1e68e06f1dbfde0e4cefc87efeba9e4643565303
-      with:
-        verbose: true
-        fail_ci_if_error: false
-        token: ${{ secrets.CODECOV_TOKEN }}

.github/workflows/import-check.yaml

@@ -1,49 +0,0 @@
-name: import-check
-
-on:
-  workflow_call:
-
-jobs:
-  # Check we don't make the situation with circular imports worse
-  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: 4cdb0bf15f04ab6b49041d5ef1bfd9644cce7f33
-        path: circular-import-fighter
-    - name: Install dependencies
-      working-directory: circular-import-fighter
-      run: make -j dependencies
-    - name: Circular import check
-      working-directory: circular-import-fighter
-      run: make -j compare "SPACK_ROOT=../old ../new"

.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

@@ -1,31 +0,0 @@
-name: Windows Paraview Nightly
-
-on:
-  schedule:
-    - cron: '0 2 * * *' # Run at 2 am
-
-defaults:
-  run:
-    shell:
-     powershell Invoke-Expression -Command "./share/spack/qa/windows_test_setup.ps1"; {0}
-
-
-jobs:
-  build-paraview-deps:
-    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 six pywin32 setuptools coverage
-    - name: Build Test
-      run: |
-        spack compiler find
-        spack external find cmake ninja win-sdk win-wdk wgl msmpi
-        spack -d install -y --cdash-upload-url https://cdash.spack.io/submit.php?project=Spack+on+Windows --cdash-track Nightly --only dependencies paraview
-        exit 0

.github/workflows/prechecks.yml

@@ -1,104 +0,0 @@
-name: prechecks
-
-on:
-  workflow_call:
-    inputs:
-      with_coverage:
-        required: true
-        type: string
-      with_packages:
-        required: true
-        type: string
-
-concurrency:
-  group: style-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
-  cancel-in-progress: true
-
-
-jobs:
-  # Validate that the code can be run on all the Python versions supported by Spack
-  validate:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-      with:
-        python-version: '3.13'
-        cache: 'pip'
-        cache-dependency-path: '.github/workflows/requirements/style/requirements.txt'
-    - name: Install Python Packages
-      run: |
-        pip install -r .github/workflows/requirements/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)
-      run: |
-        vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv var/spack/repos
-
-  # Run style checks on the files that have been changed
-  style:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      with:
-        fetch-depth: 2
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
-      with:
-        python-version: '3.13'
-        cache: 'pip'
-        cache-dependency-path: '.github/workflows/requirements/style/requirements.txt'
-    - name: Install Python packages
-      run: |
-        pip install -r .github/workflows/requirements/style/requirements.txt
-    - name: Run style tests
-      run: |
-        bin/spack style --base HEAD^1
-        bin/spack license verify
-        pylint -j $(nproc) --disable=all --enable=unspecified-encoding --ignore-paths=lib/spack/external lib
-
-  audit:
-    uses: ./.github/workflows/audit.yaml
-    secrets: inherit
-    with:
-      with_coverage: ${{ inputs.with_coverage }}
-      python_version: '3.13'
-
-  verify-checksums:
-    if: ${{ inputs.with_packages == 'true' }}
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29
-      with:
-        fetch-depth: 2
-    - name: Verify Added Checksums
-      run: |
-        bin/spack ci verify-versions HEAD^1 HEAD
-
-  # Check that spack can bootstrap the development environment on Python 3.6 - RHEL8
-  bootstrap-dev-rhel8:
-    runs-on: ubuntu-latest
-    container: registry.access.redhat.com/ubi8/ubi
-    steps:
-      - name: Install dependencies
-        run: |
-          dnf install -y \
-              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
-              make patch tcl unzip which xz
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
-      - name: Setup repo and non-root user
-        run: |
-          git --version
-          git config --global --add safe.directory '*'
-          git fetch --unshallow
-          . .github/workflows/bin/setup_git.sh
-          useradd spack-test
-          chown -R spack-test .
-      - name: Bootstrap Spack development environment
-        shell: runuser -u spack-test -- bash {0}
-        run: |
-          source share/spack/setup-env.sh
-          spack debug report
-          spack -d bootstrap now --dev
-          spack -d style -t black
-          spack unit-test -V

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

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

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

@@ -1,8 +0,0 @@
-black==25.1.0
-clingo==5.8.0
-flake8==7.2.0
-isort==6.0.1
-mypy==1.15.0
-types-six==1.17.0.20250403
-vermin==1.6.0
-pylint==3.3.6

.github/workflows/setup_git.ps1

@@ -1,3 +1,5 @@
+# (c) 2022 Lawrence Livermore National Laboratory
+
 git config --global user.email "spack@example.com"
 git config --global user.name "Test User"
 git config --global core.longpaths true

.github/workflows/unit_tests.yaml

@@ -15,32 +15,42 @@ jobs:
     strategy:
       matrix:
         os: [ubuntu-latest]
-        python-version: ['3.8', '3.9', '3.10', '3.11', '3.12']
+        python-version: ['3.7', '3.8', '3.9', '3.10', '3.11']
+        concretizer: ['clingo']
         on_develop:
         - ${{ github.ref == 'refs/heads/develop' }}
         include:
-        - python-version: '3.7'
+        - python-version: '3.11'
-          os: ubuntu-22.04
+          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
-          on_develop: false
+          concretizer: 'clingo'
-        - python-version: '3.11'
-          os: ubuntu-latest
           on_develop: false
 
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @v2
       with:
         python-version: ${{ matrix.python-version }}
     - name: Install System packages
@@ -49,13 +59,7 @@ jobs:
           # Needed for unit tests
           sudo apt-get -y install \
               coreutils cvs gfortran graphviz gnupg2 mercurial ninja-build \
-              cmake bison libbison-dev subversion
+              cmake bison libbison-dev kcov
-    # On ubuntu 24.04, kcov was removed. It may come back in some future Ubuntu
-    - name: Set up Homebrew
-      id: set-up-homebrew
-      uses: Homebrew/actions/setup-homebrew@40e9946c182a64b3db1bf51be0dcb915f7802aa9
-    - name: Install kcov with brew
-      run: "brew install kcov"
     - name: Install Python packages
       run: |
           pip install --upgrade pip setuptools pytest pytest-xdist pytest-cov
@@ -64,7 +68,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:
@@ -77,38 +81,30 @@ 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@6f51ac03b9356f520e9adb1b1b7802705f340c2b
+    - uses: codecov/codecov-action@894ff025c7b54547a9a2a1e9f228beae737ad3c2
       with:
-        name: coverage-${{ matrix.os }}-python${{ matrix.python-version }}
+        flags: unittests,linux,${{ matrix.concretizer }}
-        path: coverage
-        include-hidden-files: true
   # Test shell integration
   shell:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @v2
       with:
         python-version: '3.11'
     - name: Install System packages
       run: |
           sudo apt-get -y update
           # Needed for shell tests
-          sudo apt-get install -y coreutils csh zsh tcsh fish dash bash subversion
+          sudo apt-get install -y coreutils kcov csh zsh tcsh fish dash bash
-    # On ubuntu 24.04, kcov was removed. It may come back in some future Ubuntu
-    - name: Set up Homebrew
-      id: set-up-homebrew
-      uses: Homebrew/actions/setup-homebrew@40e9946c182a64b3db1bf51be0dcb915f7802aa9
-    - name: Install kcov with brew
-      run: "brew install kcov"
     - name: Install Python packages
       run: |
           pip install --upgrade pip setuptools pytest coverage[toml] pytest-xdist
@@ -116,17 +112,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@6f51ac03b9356f520e9adb1b1b7802705f340c2b
+    - uses: codecov/codecov-action@894ff025c7b54547a9a2a1e9f228beae737ad3c2
       with:
-        name: coverage-shell
+        flags: shelltests,linux
-        path: coverage
-        include-hidden-files: true
 
   # Test RHEL8 UBI with platform Python. This job is run
   # only on PRs modifying core Spack
@@ -137,15 +131,15 @@ jobs:
     - name: Install dependencies
       run: |
           dnf install -y \
-              bzip2 curl gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
+              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
               make patch tcl unzip which xz
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
     - name: Setup repo and non-root user
       run: |
           git --version
-          git config --global --add safe.directory '*'
+          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
@@ -158,49 +152,44 @@ jobs:
   clingo-cffi:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @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
+          share/spack/qa/run-unit-tests
-        spack bootstrap disable spack-install
+    - uses: codecov/codecov-action@894ff025c7b54547a9a2a1e9f228beae737ad3c2 # @v2.1.0
-        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@6f51ac03b9356f520e9adb1b1b7802705f340c2b
       with:
-        name: coverage-clingo-cffi
+        flags: unittests,linux,clingo
-        path: coverage
-        include-hidden-files: true
   # Run unit tests on MacOS
   macos:
-    runs-on: ${{ matrix.os }}
+    runs-on: macos-latest
     strategy:
       matrix:
-        os: [macos-13, macos-14]
+        python-version: ["3.10"]
-        python-version: ["3.11"]
     steps:
-    - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
       with:
         fetch-depth: 0
-    - uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @v2
       with:
         python-version: ${{ matrix.python-version }}
     - name: Install Python packages
@@ -209,52 +198,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[@]}"
+        $(which spack) unit-test --cov --cov-config=pyproject.toml --cov-report=xml:coverage.xml "${common_args[@]}"
-    - uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b1b7802705f340c2b
+    - uses: codecov/codecov-action@894ff025c7b54547a9a2a1e9f228beae737ad3c2
       with:
-        name: coverage-${{ matrix.os }}-python${{ matrix.python-version }}
+        flags: unittests,macos
-        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@6f51ac03b9356f520e9adb1b1b7802705f340c2b
-      with:
-        name: coverage-windows
-        path: coverage
-        include-hidden-files: true

.github/workflows/valid-style.yml

@@ -0,0 +1,86 @@
+name: style
+
+on:
+  workflow_call:
+    inputs:
+      with_coverage:
+        required: true
+        type: string
+
+concurrency:
+  group: style-${{github.ref}}-${{github.event.pull_request.number || github.run_number}}
+  cancel-in-progress: true
+
+
+jobs:
+  # Validate that the code can be run on all the Python versions
+  # supported by Spack
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @v2
+      with:
+        python-version: '3.11'
+        cache: 'pip'
+    - name: Install Python Packages
+      run: |
+        pip install --upgrade pip
+        pip install --upgrade vermin
+    - 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)
+      run: vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv var/spack/repos
+  # Run style checks on the files that have been changed
+  style:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @v2
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b # @v2
+      with:
+        python-version: '3.11'
+        cache: 'pip'
+    - name: Install Python packages
+      run: |
+        python3 -m pip install --upgrade pip setuptools types-six black==23.1.0 mypy isort clingo flake8==6.0.0
+    - name: Setup git configuration
+      run: |
+        # Need this for the git tests to succeed.
+        git --version
+        . .github/workflows/setup_git.sh
+    - name: Run style tests
+      run: |
+          share/spack/qa/run-style-tests
+  audit:
+    uses: ./.github/workflows/audit.yaml
+    with:
+      with_coverage: ${{ inputs.with_coverage }}
+      python_version: '3.11'
+  # Check that spack can bootstrap the development environment on Python 3.6 - RHEL8
+  bootstrap-dev-rhel8:
+    runs-on: ubuntu-latest
+    container: registry.access.redhat.com/ubi8/ubi
+    steps:
+      - name: Install dependencies
+        run: |
+          dnf install -y \
+              bzip2 curl file gcc-c++ gcc gcc-gfortran git gnupg2 gzip \
+              make patch tcl unzip which xz
+      - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # @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/setup_git.sh
+          useradd spack-test
+          chown -R spack-test .
+      - name: Bootstrap Spack development environment
+        shell: runuser -u spack-test -- bash {0}
+        run: |
+          source share/spack/setup-env.sh
+          spack -d bootstrap now --dev
+          spack style -t black
+          spack unit-test -V

.github/workflows/windows_python.yml

@@ -0,0 +1,80 @@
+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@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b
+      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@894ff025c7b54547a9a2a1e9f228beae737ad3c2
+      with:
+        flags: unittests,windows
+  unit-tests-cmd:
+    runs-on: windows-latest
+    steps:
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b
+      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@894ff025c7b54547a9a2a1e9f228beae737ad3c2
+      with:
+        flags: unittests,windows
+  build-abseil:
+    runs-on: windows-latest
+    steps:
+    - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
+      with:
+        fetch-depth: 0
+    - uses: actions/setup-python@57ded4d7d5e986d7296eab16560982c6dd7c923b
+      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 external find cmake
+        spack external find ninja
+        spack -d install abseil-cpp

.gitignore

@@ -201,6 +201,7 @@ tramp
 
 # Org-mode
 .org-id-locations
+*_archive
 
 # flymake-mode
 *_flymake.*

.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,735 +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.
-
-## Features in this release
-
-1. **Better error messages with condition chaining**
-
-   In v0.18, we added better error messages that could tell you what problem happened,
-   but they couldn't tell you *why* it happened. `0.21` adds *condition chaining* to the
-   solver, and Spack can now trace back through the conditions that led to an error and
-   build a tree of causes potential causes and where they came from. For example:
-
-   ```console
-   $ spack solve hdf5 ^cmake@3.0.1
-   ==> Error: concretization failed for the following reasons:
-
-      1. Cannot satisfy 'cmake@3.0.1'
-      2. Cannot satisfy 'cmake@3.0.1'
-           required because hdf5 ^cmake@3.0.1 requested from CLI
-      3. Cannot satisfy 'cmake@3.18:' and 'cmake@3.0.1
-           required because hdf5 ^cmake@3.0.1 requested from CLI
-           required because hdf5 depends on cmake@3.18: when @1.13:
-             required because hdf5 ^cmake@3.0.1 requested from CLI
-      4. Cannot satisfy 'cmake@3.12:' and 'cmake@3.0.1
-           required because hdf5 depends on cmake@3.12:
-             required because hdf5 ^cmake@3.0.1 requested from CLI
-           required because hdf5 ^cmake@3.0.1 requested from CLI
-   ```
-
-   More details in #40173.
-
-2. **OCI build caches**
-
-   You can now use an arbitrary [OCI](https://opencontainers.org) registry as a build
-   cache:
-
-   ```console
-   $ spack mirror add my_registry oci://user/image # Dockerhub
-   $ spack mirror add my_registry oci://ghcr.io/haampie/spack-test # GHCR
-   $ spack mirror set --push --oci-username ... --oci-password ... my_registry  # set login creds
-   $ spack buildcache push my_registry [specs...]
-   ```
-
-   And you can optionally add a base image to get *runnable* images:
-
-   ```console
-   $ spack buildcache push --base-image ubuntu:23.04 my_registry python
-   Pushed ... as [image]:python-3.11.2-65txfcpqbmpawclvtasuog4yzmxwaoia.spack
-
-   $ docker run --rm -it [image]:python-3.11.2-65txfcpqbmpawclvtasuog4yzmxwaoia.spack
-   ```
-
-   This creates a container image from the Spack installations on the host system,
-   without the need to run `spack install` from a `Dockerfile` or `sif` file. It also
-   addresses the inconvenience of losing binaries of dependencies when `RUN spack
-   install` fails inside `docker build`.
-
-   Further, the container image layers and build cache tarballs are the same files. This
-   means that `spack install` and `docker pull` use the exact same underlying binaries.
-   If you previously used `spack install` inside of `docker build`, this feature helps
-   you save storage by a factor two.
-
-   More details in #38358.
-
-3. **Multiple versions of build dependencies**
-
-   Increasingly, complex package builds require multiple versions of some build
-   dependencies. For example, Python packages frequently require very specific versions
-   of `setuptools`, `cython`, and sometimes different physics packages require different
-   versions of Python to build. The concretizer enforced that every solve was *unified*,
-   i.e., that there only be one version of every package. The concretizer now supports
-   "duplicate" nodes for *build dependencies*, but enforces unification through
-   transitive link and run dependencies. This will allow it to better resolve complex
-   dependency graphs in ecosystems like Python, and it also gets us very close to
-   modeling compilers as proper dependencies.
-
-   This change required a major overhaul of the concretizer, as well as a number of
-   performance optimizations. See #38447, #39621.
-
-4. **Cherry-picking virtual dependencies**
-
-   You can now select only a subset of virtual dependencies from a spec that may provide
-   more. For example, if you want `mpich` to be your `mpi` provider, you can be explicit
-   by writing:
-
-   ```
-   hdf5 ^[virtuals=mpi] mpich
-   ```
-
-   Or, if you want to use, e.g., `intel-parallel-studio` for `blas` along with an external
-   `lapack` like `openblas`, you could write:
-
-   ```
-   strumpack ^[virtuals=mpi] intel-parallel-studio+mkl ^[virtuals=lapack] openblas
-   ```
-
-   The `virtuals=mpi` is an edge attribute, and dependency edges in Spack graphs now
-   track which virtuals they satisfied. More details in #17229 and #35322.
-
-   Note for packaging: in Spack 0.21 `spec.satisfies("^virtual")` is true if and only if
-   the package specifies `depends_on("virtual")`. This is different from Spack 0.20,
-   where depending on a provider implied depending on the virtual provided. See #41002
-   for an example where `^mkl` was being used to test for several `mkl` providers in a
-   package that did not depend on `mkl`.
-
-5. **License directive**
-
-   Spack packages can now have license metadata, with the new `license()` directive:
-
-   ```python
-       license("Apache-2.0")
-   ```
-
-   Licenses use [SPDX identifiers](https://spdx.org/licenses), and you can use SPDX
-   expressions to combine them:
-
-   ```python
-       license("Apache-2.0 OR MIT")
-   ```
-
-   Like other directives in Spack, it's conditional, so you can handle complex cases like
-   Spack itself:
-
-   ```python
-      license("LGPL-2.1", when="@:0.11")
-      license("Apache-2.0 OR MIT", when="@0.12:")
-   ```
-
-   More details in #39346, #40598.
-
-6. **`spack deconcretize` command**
-
-   We are getting close to having a `spack update` command for environments, but we're
-   not quite there yet. This is the next best thing. `spack deconcretize` gives you
-   control over what you want to update in an already concrete environment. If you have
-   an environment built with, say, `meson`, and you want to update your `meson` version,
-   you can run:
-
-   ```console
-   spack deconcretize meson
-   ```
-
-   and have everything that depends on `meson` rebuilt the next time you run `spack
-   concretize`. In a future Spack version, we'll handle all of this in a single command,
-   but for now you can use this to drop bits of your lockfile and resolve your
-   dependencies again. More in #38803.
-
-7. **UI Improvements**
-
-   The venerable `spack info` command was looking shabby compared to the rest of Spack's
-   UI, so we reworked it to have a bit more flair. `spack info` now makes much better
-   use of terminal space and shows variants, their values, and their descriptions much
-   more clearly. Conditional variants are grouped separately so you can more easily
-   understand how packages are structured. More in #40998.
-
-   `spack checksum` now allows you to filter versions from your editor, or by version
-   range. It also notifies you about potential download URL changes. See #40403.
-
-8. **Environments can include definitions**
-
-   Spack did not previously support using `include:` with The
-   [definitions](https://spack.readthedocs.io/en/latest/environments.html#spec-list-references)
-   section of an environment, but now it does. You can use this to curate lists of specs
-   and more easily reuse them across environments. See #33960.
-
-9. **Aliases**
-
-   You can now add aliases to Spack commands in `config.yaml`, e.g. this might enshrine
-   your favorite args to `spack find` as `spack f`:
-
-   ```yaml
-   config:
-     aliases:
-       f: find -lv
-   ```
-
-   See #17229.
-
-10. **Improved autoloading of modules**
-
-    Spack 0.20 was the first release to enable autoloading of direct dependencies in
-    module files.
-
-    The downside of this was that `module avail` and `module load` tab completion would
-    show users too many modules to choose from, and many users disabled generating
-    modules for dependencies through `exclude_implicits: true`. Further, it was
-    necessary to keep hashes in module names to avoid file name clashes.
-
-    In this release, you can start using `hide_implicits: true` instead, which exposes
-    only explicitly installed packages to the user, while still autoloading
-    dependencies. On top of that, you can safely use `hash_length: 0`, as this config
-    now only applies to the modules exposed to the user -- you don't have to worry about
-    file name clashes for hidden dependencies.
-
-   Note: for `tcl` this feature requires Modules 4.7 or higher
-
-11. **Updated container labeling**
-
-    Nightly Docker images from the `develop` branch will now be tagged as `:develop` and
-    `:nightly`. The `:latest` tag is no longer associated with `:develop`, but with the
-    latest stable release. Releases will be tagged with `:{major}`, `:{major}.{minor}`
-    and `:{major}.{minor}.{patch}`. `ubuntu:18.04` has also been removed from the list of
-    generated Docker images, as it is no longer supported. See #40593.
-
-## Other new commands and directives
-
-* `spack env activate` without arguments now loads a `default` environment that you do
-  not have to create (#40756).
-* `spack find -H` / `--hashes`: a new shortcut for piping `spack find` output to
-  other commands (#38663)
-* Add `spack checksum --verify`, fix `--add` (#38458)
-* New `default_args` context manager factors out common args for directives (#39964)
-* `spack compiler find --[no]-mixed-toolchain` lets you easily mix `clang` and
-  `gfortran` on Linux (#40902)
-
-## Performance improvements
-
-* `spack external find` execution is now much faster (#39843)
-* `spack location -i` now much faster on success (#40898)
-* Drop redundant rpaths post install (#38976)
-* ASP-based solver: avoid cycles in clingo using hidden directive (#40720)
-* Fix multiple quadratic complexity issues in environments (#38771)
-
-## Other new features of note
-
-* archspec: update to v0.2.2, support for Sapphire Rapids, Power10, Neoverse V2 (#40917)
-* Propagate variants across nodes that don't have that variant (#38512)
-* Implement fish completion (#29549)
-* Can now distinguish between source/binary mirror; don't ping mirror.spack.io as much (#34523)
-* Improve status reporting on install (add [n/total] display) (#37903)
-
-## Windows
-
-This release has the best Windows support of any Spack release yet, with numerous
-improvements and much larger swaths of tests passing:
-
-* MSVC and SDK improvements (#37711, #37930, #38500, #39823, #39180)
-* Windows external finding: update default paths; treat .bat as executable on Windows (#39850)
-* Windows decompression: fix removal of intermediate file (#38958)
-* Windows: executable/path handling (#37762)
-* Windows build systems: use ninja and enable tests (#33589)
-* Windows testing (#36970, #36972, #36973, #36840, #36977, #36792, #36834, #34696, #36971)
-* Windows PowerShell support (#39118, #37951)
-* Windows symlinking and libraries (#39933, #38599, #34701, #38578, #34701)
-
-## Notable refactors
-* User-specified flags take precedence over others in Spack compiler wrappers (#37376)
-* Improve setup of build, run, and test environments (#35737, #40916)
-* `make` is no longer a required system dependency of Spack (#40380)
-* Support Python 3.12 (#40404, #40155, #40153)
-* docs: Replace package list with packages.spack.io (#40251)
-* Drop Python 2 constructs in Spack (#38720, #38718, #38703)
-
-## Binary cache and stack updates
-* e4s arm stack: duplicate and target neoverse v1 (#40369)
-* Add macOS ML CI stacks (#36586)
-* E4S Cray CI Stack (#37837)
-* e4s cray: expand spec list (#38947)
-* e4s cray sles ci: expand spec list (#39081)
-
-## Removals, deprecations, and syntax changes
-* ASP: targets, compilers and providers soft-preferences are only global (#31261)
-* Parser: fix ambiguity with whitespace in version ranges (#40344)
-* Module file generation is disabled by default; you'll need to enable it to use it (#37258)
-* Remove deprecated "extra_instructions" option for containers (#40365)
-* Stand-alone test feature deprecation postponed to v0.22 (#40600)
-* buildcache push: make `--allow-root` the default and deprecate the option (#38878)
-
-## Notable Bugfixes
-* Bugfix: propagation of multivalued variants (#39833)
-* Allow `/` in git versions (#39398)
-* Fetch & patch: actually acquire stage lock, and many more issues (#38903)
-* Environment/depfile: better escaping of targets with Git versions (#37560)
-* Prevent "spack external find" to error out on wrong permissions (#38755)
-* lmod: allow core compiler to be specified with a version range (#37789)
-
-## Spack community stats
-
-* 7,469 total packages, 303 new since `v0.20.0`
-    * 150 new Python packages
-    * 34 new R packages
-* 353 people contributed to this release
-    * 336 committers to packages
-    * 65 committers to core
-
-
-# v0.20.3 (2023-10-31)
-
-## Bugfixes
-
-- Fix a bug where `spack mirror set-url` would drop configured connection info (reverts #34210)
-- Fix a minor issue with package hash computation for Python 3.12 (#40328)
-
-
 # v0.20.2 (2023-10-03)
 
 ## Features in this release
@@ -751,7 +19,6 @@ Spack now supports Python 3.12 (#40155)
 - Fix multiple performance regressions in environments (#38771)
 - Add more ignored modules to `pyproject.toml` for `mypy` (#38769)
 
-
 # v0.20.1 (2023-07-10)
 
 ## Spack Bugfixes

CITATION.cff

@@ -27,57 +27,12 @@
 # And here's the CITATION.cff format:
 #
 cff-version: 1.2.0
-type: software
 message: "If you are referencing Spack in a publication, please cite the paper below."
-title: "The Spack Package Manager: Bringing Order to HPC Software Chaos"
-abstract: >-
-  Large HPC centers spend considerable time supporting software for thousands of users, but the
-  complexity of HPC software is quickly outpacing the capabilities of existing software management
-  tools. Scientific applications require specific versions of compilers, MPI, and other dependency
-  libraries, so using a single, standard software stack is infeasible. However, managing many
-  configurations is difficult because the configuration space is combinatorial in size. We
-  introduce Spack, a tool used at Lawrence Livermore National Laboratory to manage this complexity.
-  Spack provides a novel, re- cursive specification syntax to invoke parametric builds of packages
-  and dependencies. It allows any number of builds to coexist on the same system, and it ensures
-  that installed packages can find their dependencies, regardless of the environment. We show
-  through real-world use cases that Spack supports diverse and demanding applications, bringing
-  order to HPC software chaos.
 preferred-citation:
-  title: "The Spack Package Manager: Bringing Order to HPC Software Chaos"
   type: conference-paper
-  url: "https://tgamblin.github.io/pubs/spack-sc15.pdf"
+  doi: "10.1145/2807591.2807623"
+  url: "https://github.com/spack/spack"
   authors:
-    - family-names: "Gamblin"
-      given-names: "Todd"
-    - family-names: "LeGendre"
-      given-names: "Matthew"
-    - family-names: "Collette"
-      given-names: "Michael R."
-    - family-names: "Lee"
-      given-names: "Gregory L."
-    - family-names: "Moody"
-      given-names: "Adam"
-    - family-names: "de Supinski"
-      given-names: "Bronis R."
-    - family-names: "Futral"
-      given-names: "Scott"
-  conference:
-    name: "Supercomputing 2015 (SC’15)"
-    city: "Austin"
-    region: "Texas"
-    country: "US"
-    date-start: 2015-11-15
-    date-end: 2015-11-20
-  month: 11
-  year: 2015
-  identifiers:
-    - description: "The concept DOI of the work."
-      type: doi
-      value: 10.1145/2807591.2807623
-    - description: "The DOE Document Release Number of the work"
-      type: other
-      value: "LLNL-CONF-669890"
-authors:
   - family-names: "Gamblin"
     given-names: "Todd"
   - family-names: "LeGendre"
@@ -92,3 +47,12 @@ authors:
     given-names: "Bronis R."
   - family-names: "Futral"
     given-names: "Scott"
+  title: "The Spack Package Manager: Bringing Order to HPC Software Chaos"
+  conference:
+    name: "Supercomputing 2015 (SC’15)"
+    city: "Austin"
+    region: "Texas"
+    country: "USA"
+  month: November 15-20
+  year: 2015
+  notes: LLNL-CONF-669890

COPYRIGHT

@@ -8,9 +8,8 @@ or http://www.apache.org/licenses/LICENSE-2.0) or the MIT license,
 Copyrights and patents in the Spack project are retained by contributors.
 No copyright assignment is required to contribute to Spack.
 
-Spack was originally developed in 2013 by Lawrence Livermore National
+Spack was originally distributed under the LGPL-2.1 license. Consent from
-Security, LLC. It was originally distributed under the LGPL-2.1 license.
+contributors to relicense to Apache-2.0/MIT is documented at
-Consent from contributors to relicense to Apache-2.0/MIT is documented at
 https://github.com/spack/spack/issues/9137.
 
 
@@ -103,6 +102,6 @@ PackageName: sbang
 PackageHomePage: https://github.com/spack/sbang
 PackageLicenseDeclared: Apache-2.0 OR MIT
 
-PackageName: typing_extensions
+PackageName: six
-PackageHomePage: https://pypi.org/project/typing-extensions/
+PackageHomePage: https://pypi.python.org/pypi/six
-PackageLicenseDeclared: Python-2.0
+PackageLicenseDeclared: MIT

LICENSE-MIT

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) Spack Project Developers.
+Copyright (c) 2013-2023 LLNS, LLC and other Spack Project Developers.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

README.md

@@ -1,38 +1,16 @@
-<div align="left">
+# <img src="https://cdn.rawgit.com/spack/spack/develop/share/spack/logo/spack-logo.svg" width="64" valign="middle" alt="Spack"/> Spack
 
-<h2>
+[![Unit Tests](https://github.com/spack/spack/workflows/linux%20tests/badge.svg)](https://github.com/spack/spack/actions)
-<picture>
+[![Bootstrapping](https://github.com/spack/spack/actions/workflows/bootstrap.yml/badge.svg)](https://github.com/spack/spack/actions/workflows/bootstrap.yml)
-  <source media="(prefers-color-scheme: dark)" srcset="https://cdn.rawgit.com/spack/spack/develop/share/spack/logo/spack-logo-white-text.svg" width="250">
+[![codecov](https://codecov.io/gh/spack/spack/branch/develop/graph/badge.svg)](https://codecov.io/gh/spack/spack)
-  <source media="(prefers-color-scheme: light)" srcset="https://cdn.rawgit.com/spack/spack/develop/share/spack/logo/spack-logo-text.svg" width="250">
+[![Containers](https://github.com/spack/spack/actions/workflows/build-containers.yml/badge.svg)](https://github.com/spack/spack/actions/workflows/build-containers.yml)
-  <img alt="Spack" src="https://cdn.rawgit.com/spack/spack/develop/share/spack/logo/spack-logo-text.svg" width="250">
+[![Read the Docs](https://readthedocs.org/projects/spack/badge/?version=latest)](https://spack.readthedocs.io)
-</picture>
+[![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
-
+[![Slack](https://slack.spack.io/badge.svg)](https://slack.spack.io)
-<br>
-<br clear="all">
-
-<a href="https://github.com/spack/spack/actions/workflows/ci.yml"><img src="https://github.com/spack/spack/workflows/ci/badge.svg" alt="CI Status"></a>
-<a href="https://github.com/spack/spack/actions/workflows/bootstrapping.yml"><img src="https://github.com/spack/spack/actions/workflows/bootstrap.yml/badge.svg" alt="Bootstrap Status"></a>
-<a href="https://github.com/spack/spack/actions/workflows/build-containers.yml"><img src="https://github.com/spack/spack/actions/workflows/build-containers.yml/badge.svg" alt="Containers Status"></a>
-<a href="https://spack.readthedocs.io"><img src="https://readthedocs.org/projects/spack/badge/?version=latest" alt="Documentation Status"></a>
-<a href="https://codecov.io/gh/spack/spack"><img src="https://codecov.io/gh/spack/spack/branch/develop/graph/badge.svg" alt="Code coverage"/></a>
-<a href="https://slack.spack.io"><img src="https://slack.spack.io/badge.svg" alt="Slack"/></a>
-<a href="https://matrix.to/#/#spack-space:matrix.org"><img src="https://img.shields.io/matrix/spack-space%3Amatrix.org?label=matrix" alt="Matrix"/></a>
-
-</h2>
-
-**[Getting Started] &nbsp; • &nbsp; [Config] &nbsp; • &nbsp; [Community] &nbsp; • &nbsp; [Contributing] &nbsp; • &nbsp; [Packaging Guide]**
-
-[Getting Started]: https://spack.readthedocs.io/en/latest/getting_started.html
-[Config]: https://spack.readthedocs.io/en/latest/configuration.html
-[Community]: #community
-[Contributing]: https://spack.readthedocs.io/en/latest/contribution_guide.html
-[Packaging Guide]: https://spack.readthedocs.io/en/latest/packaging_guide.html
-
-</div>
 
 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,41 +24,12 @@ See the
 [Feature Overview](https://spack.readthedocs.io/en/latest/features.html)
 for examples and highlights.
 
-Installation
+To install spack and your first package, make sure you have Python.
-----------------
-
-To install spack, first make sure you have Python & Git.
 Then:
 
-```bash
+    $ git clone -c feature.manyFiles=true https://github.com/spack/spack.git
-git clone -c feature.manyFiles=true --depth=2 https://github.com/spack/spack.git
+    $ cd spack/bin
-```
+    $ ./spack install zlib
-
-<details>
-<summary>What are <code>manyFiles=true</code> and <code>--depth=2</code>?</summary>
-<br>
-
-> `-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.
-
-</details>
-
-```bash
-# For bash/zsh/sh
-. spack/share/spack/setup-env.sh
-
-# For tcsh/csh
-source spack/share/spack/setup-env.csh
-
-# For fish
-. spack/share/spack/setup-env.fish
-```
-
-```bash
-# Now you're ready to install a package!
-spack install zlib-ng
-```
 
 Documentation
 ----------------
@@ -94,7 +43,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.
@@ -113,14 +62,10 @@ Resources:
 
 * **Slack workspace**: [spackpm.slack.com](https://spackpm.slack.com).
   To get an invitation, visit [slack.spack.io](https://slack.spack.io).
-* **Matrix space**: [#spack-space:matrix.org](https://matrix.to/#/#spack-space:matrix.org):
+* [**Github Discussions**](https://github.com/spack/spack/discussions): not just for discussions, also Q&A.
-  [bridged](https://github.com/matrix-org/matrix-appservice-slack#matrix-appservice-slack) to Slack.
+* **Mailing list**: [groups.google.com/d/forum/spack](https://groups.google.com/d/forum/spack)
-* [**Github Discussions**](https://github.com/spack/spack/discussions):
+* **Twitter**: [@spackpm](https://twitter.com/spackpm). Be sure to
-  for Q&A and discussions. Note the pinned discussions for announcements.
-* **X**: [@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.
 
 Contributing
 ------------------------

SECURITY.md

@@ -2,26 +2,24 @@
 
 ## Supported Versions
 
-We provide security updates for `develop` and for the last two
+We provide security updates for the following releases.
-stable (`0.x`) release series of Spack. Security updates will be
-made available as patch (`0.x.1`, `0.x.2`, etc.) releases.
-
 For more on Spack's release structure, see
 [`README.md`](https://github.com/spack/spack#releases).
 
+
+| Version | Supported          |
+| ------- | ------------------ |
+| develop | :white_check_mark: |
+| 0.19.x  | :white_check_mark: |
+| 0.18.x  | :white_check_mark: |
+
 ## Reporting a Vulnerability
 
-You can report a vulnerability using GitHub's private reporting
+To report a vulnerability or other security
-feature:
+issue, email maintainers@spack.io.
 
-1. Go to [github.com/spack/spack/security](https://github.com/spack/spack/security).
+You can expect to hear back within two days.
-2. Click "Report a vulnerability" in the upper right corner of that page.
+If your security issue is accepted, we will do
-3. Fill out the form and submit your draft security advisory.
+our best to release a fix within a week. If
-
+fixing the issue will take longer than this,
-More details are available in
+we will discuss timeline options with you.
-[GitHub's docs](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability).
-
-You can expect to hear back about security issues within two days.
-If your security issue is accepted, we will do our best to release
-a fix within a week. If fixing the issue will take longer than
-this, we will discuss timeline options with you.

bin/haspywin.py

@@ -1,4 +1,5 @@
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 import subprocess

bin/sbang

@@ -1,6 +1,7 @@
 #!/bin/sh
 #
-# Copyright sbang project developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# sbang project developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

bin/spack

@@ -1,7 +1,8 @@
 #!/bin/sh
 # -*- python -*-
 #
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -24,7 +25,10 @@ exit 1
 # Line above is a shell no-op, and ends a python multi-line comment.
 # The code above runs this file with our preferred python interpreter.
 
+from __future__ import print_function
+
 import os
+import os.path
 import sys
 
 min_python3 = (3, 6)

bin/spack-python

@@ -1,6 +1,7 @@
 #!/bin/sh
 #
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -21,4 +22,4 @@
 #
 # This is compatible across platforms.
 #
-exec spack python "$@"
+exec /usr/bin/env spack python "$@"

bin/spack.bat

@@ -1,4 +1,5 @@
-:: Copyright Spack Project Developers. See COPYRIGHT file for details.
+:: Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+:: Spack Project Developers. See the top-level COPYRIGHT file for details.
 ::
 :: SPDX-License-Identifier: (Apache-2.0 OR MIT)
 ::#######################################################################
@@ -13,7 +14,7 @@
 ::
 @echo off
 
-set spack="%SPACK_ROOT%"\bin\spack
+set spack=%SPACK_ROOT%\bin\spack
 
 ::#######################################################################
 :: This is a wrapper around the spack command that forwards calls to
@@ -50,43 +51,65 @@ setlocal enabledelayedexpansion
 :: subcommands will never start with '-'
 :: everything after the subcommand is an arg
 
-
+:: we cannot allow batch "for" loop to directly process CL args
+:: a number of batch reserved characters are commonly passed to
+:: spack and allowing batch's "for" method to process the raw inputs
+:: results in a large number of formatting issues
+:: instead, treat the entire CLI as one string
+:: and split by space manually
+:: capture cl args in variable named cl_args
+set cl_args=%*
 :process_cl_args
-rem Set first cl argument (denoted by %1) to be processed
+rem  tokens=1* returns the first processed token produced
-set t=%1
+rem  by tokenizing the input string cl_args on spaces into
-rem shift moves all cl positional arguments left by one
+rem  the named variable %%g
-rem meaning %2 is now %1, this allows us to iterate over each
+rem  While this make look like a for loop, it only
-rem argument
+rem  executes a single time for each of the cl args
-shift
+rem  the actual iterative loop is performed by the
-rem assign next "first" cl argument to cl_args, will be null when
+rem  goto process_cl_args stanza
-rem there are now further arguments to process
+rem  we are simply leveraging the "for" method's string
-set cl_args=%1
+rem  tokenization
-if "!t:~0,1!" == "-" (
+for /f "tokens=1*" %%g in ("%cl_args%") do (
-    if defined _sp_subcommand (
+    set t=%%~g
-        rem  We already have a subcommand, processing args now
+    rem  remainder of string is composed into %%h
+    rem  these are the cl args yet to be processed
+    rem  assign cl_args var to only the args to be processed
+    rem  effectively discarding the current arg %%g
+    rem  this will be nul when we have no further tokens to process
+    set cl_args=%%h
+    rem  process the first space delineated cl arg
+    rem  of this iteration
+    if "!t:~0,1!" == "-" (
+        if defined _sp_subcommand (
+            rem  We already have a subcommand, processing args now
+            if not defined _sp_args (
+                set "_sp_args=!t!"
+            ) else (
+                set "_sp_args=!_sp_args! !t!"
+            )
+        ) else (
+            if not defined _sp_flags (
+                set "_sp_flags=!t!"
+                shift
+            ) else (
+                set "_sp_flags=!_sp_flags! !t!"
+                shift
+            )
+        )
+    ) else if not defined _sp_subcommand (
+        set "_sp_subcommand=!t!"
+        shift
+    ) else (
         if not defined _sp_args (
             set "_sp_args=!t!"
+            shift
         ) else (
             set "_sp_args=!_sp_args! !t!"
+            shift
         )
-    ) else (
-        if not defined _sp_flags (
-            set "_sp_flags=!t!"
-        ) else (
-            set "_sp_flags=!_sp_flags! !t!"
-        )
-    )
-) else if not defined _sp_subcommand (
-    set "_sp_subcommand=!t!"
-) else (
-    if not defined _sp_args (
-        set "_sp_args=!t!"
-    ) else (
-        set "_sp_args=!_sp_args! !t!"
     )
 )
-
+rem  if this is not nil, we have more tokens to process
-rem  if this is not nu;ll, we have more tokens to process
 rem  start above process again with remaining unprocessed cl args
 if defined cl_args goto :process_cl_args
 
@@ -187,27 +210,25 @@ if NOT "%_sp_args%"=="%_sp_args:--help=%" (
 goto :end_switch
 
 :case_load
-if NOT defined _sp_args (
+:: If args contain --sh, --csh, or -h/--help: just execute.
-   exit /B 0
+if defined _sp_args (
-)
+    if NOT "%_sp_args%"=="%_sp_args:--help=%" (
-
+        goto :default_case
-:: If args contain --bat, or -h/--help: just execute.
+    ) else if NOT "%_sp_args%"=="%_sp_args: -h=%" (
-if NOT "%_sp_args%"=="%_sp_args:--help=%" (
+        goto :default_case
-    goto :default_case
+    ) else if NOT "%_sp_args%"=="%_sp_args:--bat=%" (
-) else if NOT "%_sp_args%"=="%_sp_args:-h=%" (
+        goto :default_case
-    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
 )
 
 for /f "tokens=* USEBACKQ" %%I in (
-    `python "%spack%" %_sp_flags% %_sp_subcommand% --bat %_sp_args%`
+    `python "%spack%" %_sp_flags% %_sp_subcommand% --bat %_sp_args%`) do %%I
-    ) 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

@@ -1,147 +0,0 @@
-#  Copyright Spack Project Developers. See COPYRIGHT file for details.
-
-#  SPDX-License-Identifier: (Apache-2.0 OR MIT)
-# #######################################################################
-
-function Compare-CommonArgs {
-    $CMDArgs = $args[0]
-    # These aruments take precedence and call for no futher parsing of arguments
-    # invoke actual Spack entrypoint with that context and exit after
-    "--help", "-h", "--version", "-V" | ForEach-Object {
-        $arg_opt = $_
-        if(($CMDArgs) -and ([bool]($CMDArgs.Where({$_ -eq $arg_opt})))) {
-            return $true
-        }
-    }
-    return $false
-}
-
-function Read-SpackArgs {
-    $SpackCMD_params = @()
-    $SpackSubCommand = $NULL
-    $SpackSubCommandArgs = @()
-    $args_ = $args[0]
-    $args_ | ForEach-Object {
-        if (!$SpackSubCommand) {
-            if($_.SubString(0,1) -eq "-")
-            {
-                $SpackCMD_params += $_
-            }
-            else{
-                $SpackSubCommand = $_
-            }
-        }
-        else{
-            $SpackSubCommandArgs += $_
-        }
-    }
-    return $SpackCMD_params, $SpackSubCommand, $SpackSubCommandArgs
-}
-
-function Set-SpackEnv {
-    # This method is responsible
-    # for processing the return from $(spack <command>)
-    # which are returned as System.Object[]'s containing
-    # a list of env commands
-    # Invoke-Expression can only handle one command at a time
-    # so we iterate over the list to invoke the env modification
-    # expressions one at a time
-    foreach($envop in $args[0]){
-        Invoke-Expression $envop
-    }
-}
-
-
-function Invoke-SpackCD {
-    if (Compare-CommonArgs $SpackSubCommandArgs) {
-        python "$Env:SPACK_ROOT/bin/spack" cd -h
-    }
-    else {
-        $LOC = $(python "$Env:SPACK_ROOT/bin/spack" location $SpackSubCommandArgs)
-        if (($NULL -ne $LOC)){
-            if ( Test-Path -Path $LOC){
-                Set-Location $LOC
-            }
-            else{
-                exit 1
-            }
-        }
-        else {
-            exit 1
-        }
-    }
-}
-
-function Invoke-SpackEnv {
-    if (Compare-CommonArgs $SpackSubCommandArgs[0]) {
-        python "$Env:SPACK_ROOT/bin/spack" env -h
-    }
-    else {
-        $SubCommandSubCommand = $SpackSubCommandArgs[0]
-        $SubCommandSubCommandArgs = $SpackSubCommandArgs[1..$SpackSubCommandArgs.Count]
-        switch ($SubCommandSubCommand) {
-            "activate" {
-                if (Compare-CommonArgs $SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                elseif ([bool]($SubCommandSubCommandArgs.Where({$_ -eq "--pwsh"}))) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                elseif (!$SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env activate $SubCommandSubCommandArgs
-                }
-                else {
-                    $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params env activate "--pwsh" $SubCommandSubCommandArgs)
-                    Set-SpackEnv $SpackEnv
-                }
-            }
-            "deactivate" {
-                if ([bool]($SubCommandSubCommandArgs.Where({$_ -eq "--pwsh"}))) {
-                    python"$Env:SPACK_ROOT/bin/spack" env deactivate $SubCommandSubCommandArgs
-                }
-                elseif($SubCommandSubCommandArgs) {
-                    python "$Env:SPACK_ROOT/bin/spack" env deactivate -h
-                }
-                else {
-                    $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params env deactivate "--pwsh")
-                    Set-SpackEnv $SpackEnv
-                }
-            }
-            default {python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs}
-        }
-    }
-}
-
-function Invoke-SpackLoad {
-    if (Compare-CommonArgs $SpackSubCommandArgs) {
-        python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    }
-    elseif ([bool]($SpackSubCommandArgs.Where({($_ -eq "--pwsh") -or ($_ -eq "--list")}))) {
-        python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    }
-    else {
-        $SpackEnv = $(python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand "--pwsh" $SpackSubCommandArgs)
-        Set-SpackEnv $SpackEnv
-    }
-}
-
-
-$SpackCMD_params, $SpackSubCommand, $SpackSubCommandArgs = Read-SpackArgs $args
-
-if (Compare-CommonArgs $SpackCMD_params) {
-    python "$Env:SPACK_ROOT/bin/spack" $SpackCMD_params $SpackSubCommand $SpackSubCommandArgs
-    exit $LASTEXITCODE
-}
-
-# Process Spack commands with special conditions
-# all other commands are piped directly to Spack
-switch($SpackSubCommand)
-{
-    "cd"     {Invoke-SpackCD}
-    "env"    {Invoke-SpackEnv}
-    "load"   {Invoke-SpackLoad}
-    "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%
+:: Check if Python is on the PATH
-%comspec% /K
+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

bin/spack_pwsh.ps1

@@ -1,4 +1,5 @@
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

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
+  - name: 'github-actions-v0.4'
-    metadata: $spack/share/spack/bootstrap/github-actions-v0.6
+    metadata: $spack/share/spack/bootstrap/github-actions-v0.4
-  - name: github-actions-v0.5
+  - name: 'github-actions-v0.3'
-    metadata: $spack/share/spack/bootstrap/github-actions-v0.5
+    metadata: $spack/share/spack/bootstrap/github-actions-v0.3
-  - name: spack-install
+  - 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.4: true
-    github-actions-v0.5: true
+    github-actions-v0.3: 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
@@ -36,56 +36,3 @@ concretizer:
   # on each root spec, allowing different versions and variants of the same package in
   # an environment.
   unify: true
-  # 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.)
-    # "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
-    strategy: minimal
-    # Maximum number of duplicates in a DAG, when using a strategy that allows duplicates. "default" is the
-    # number used if there isn't a more specific alternative
-    max_dupes:
-      default: 1
-      # Virtuals
-      c: 2
-      cxx: 2
-      fortran: 1
-      # Regular packages
-      cmake: 2
-      gmake: 2
-      python: 2
-      python-venv: 2
-      py-cython: 2
-      py-flit-core: 2
-      py-pip: 2
-      py-setuptools: 2
-      py-wheel: 2
-      xcb-proto: 2
-      # Compilers
-      gcc: 2
-      llvm: 2
-  # 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
-
-  # Static analysis may reduce the concretization time by generating smaller ASP problems, in
-  # cases where there are requirements that prevent part of the search space to be explored.
-  static_analysis: false

etc/spack/defaults/config.yaml

@@ -19,7 +19,7 @@ config:
   install_tree:
     root: $spack/opt/spack
     projections:
-      all: "{architecture.platform}-{architecture.target}/{name}-{version}-{hash}"
+      all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}"
     # install_tree can include an optional padded length (int or boolean)
     # default is False (do not pad)
     # if padded_length is True, Spack will pad as close to the system max path
@@ -90,9 +90,10 @@ config:
   misc_cache: $user_cache_path/cache
 
 
-  # Abort downloads after this many seconds if not data is received.
+  # Timeout in seconds used for downloading sources etc. This only applies
-  # Setting this to 0 will disable the timeout.
+  # to the connection phase and can be increased for slow connections or
-  connect_timeout: 30
+  # servers. 0 means no timeout.
+  connect_timeout: 10
 
 
   # If this is false, tools like curl that use SSL will not verify
@@ -100,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
@@ -114,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
@@ -163,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
@@ -193,22 +211,15 @@ config:
     # executables with many dependencies, in particular on slow filesystems.
     bind: false
 
-    # Controls the handling of missing dynamic libraries after installation.
-    # Options are ignore (default), warn, or error. If set to error, the
-    # installation fails if installed binaries reference dynamic libraries that
-    # are not found in their specified rpaths.
-    missing_library_policy: ignore
-
 
   # Set to 'false' to allow installation on filesystems that doesn't allow setgid bit
   # manipulation by unprivileged user (e.g. AFS)
   allow_sgid: true
 
-  # Whether to show status information during building and installing packages.
+  # Whether to set the terminal title to display status information during
-  # This gives information about Spack's current progress as well as the current
+  # building and installing packages. This gives information about Spack's
-  # and total number of packages. Information is shown both in the terminal
+  # current progress as well as the current and total number of packages.
-  # title and inline.
+  terminal_title: false
-  install_status: true
 
   # Number of seconds a buildcache's index.json is cached locally before probing
   # for updates, within a single Spack invocation. Defaults to 10 minutes.
@@ -217,11 +228,3 @@ config:
   flags:
     # Whether to keep -Werror flags active in package builds.
     keep_werror: 'none'
-
-  # A mapping of aliases that can be used to define new commands. For instance,
-  # `sp: spec -I` will define a new command `sp` that will execute `spec` with
-  # the `-I` argument. Aliases cannot override existing commands.
-  aliases:
-    concretise: concretize
-    containerise: containerize
-    rm: remove

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

@@ -15,18 +15,18 @@
 # -------------------------------------------------------------------------
 packages:
   all:
+    compiler:
+    - apple-clang
+    - clang
+    - gcc
+    - intel
     providers:
-      c: [apple-clang, llvm, gcc]
-      cxx: [apple-clang, llvm, gcc]
       elf: [libelf]
-      fortran: [gcc]
       fuse: [macfuse]
       gl: [apple-gl]
       glu: [apple-glu]
       unwind: [apple-libunwind]
       uuid: [apple-libuuid]
-  apple-clang:
-    buildable: false
   apple-gl:
     buildable: false
     externals:
@@ -50,13 +50,4 @@ packages:
     # Apple bundles libuuid in libsystem_c version 1353.100.2,
     # although the version number used here isn't critical
     - spec: apple-libuuid@1353.100.2
-      prefix: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
+      prefix: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-  c:
-    prefer:
-    - apple-clang
-  cxx:
-    prefer:
-    - apple-clang
-  fortran:
-    prefer:
-    - gcc

etc/spack/defaults/mirrors.yaml

@@ -1,4 +1,2 @@
 mirrors:
-  spack-public:
+  spack-public: https://mirror.spack.io
-    binary: false
-    url: https://mirror.spack.io

etc/spack/defaults/packages.yaml

@@ -15,19 +15,15 @@
 # -------------------------------------------------------------------------
 packages:
   all:
+    compiler: [gcc, intel, pgi, clang, xl, nag, fj, aocc]
     providers:
       awk: [gawk]
-      armci: [armcimpi]
       blas: [openblas, amdblis]
-      c: [gcc, llvm, intel-oneapi-compilers]
-      cxx: [gcc, llvm, intel-oneapi-compilers]
       D: [ldc]
       daal: [intel-oneapi-daal]
       elf: [elfutils]
       fftw-api: [fftw, amdfftw]
       flame: [libflame, amdlibflame]
-      fortran: [gcc, llvm, intel-oneapi-compilers]
-      fortran-rt: [gcc-runtime, intel-oneapi-runtime]
       fuse: [libfuse]
       gl: [glx, osmesa]
       glu: [mesa-glu, openglu]
@@ -35,14 +31,12 @@ packages:
       go-or-gccgo-bootstrap: [go-bootstrap, gcc]
       iconv: [libiconv]
       ipp: [intel-oneapi-ipp]
-      java: [openjdk, jdk]
+      java: [openjdk, jdk, ibm-java]
       jpeg: [libjpeg-turbo, libjpeg]
       lapack: [openblas, amdlibflame]
-      libc: [glibc, musl]
+      libglx: [mesa+glx, mesa18+glx]
-      libgfortran: [gcc-runtime]
-      libglx: [mesa+glx]
-      libifcore: [intel-oneapi-runtime]
       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]
@@ -55,7 +49,6 @@ packages:
       pbs: [openpbs, torque]
       pil: [py-pillow]
       pkgconfig: [pkgconf, pkg-config]
-      qmake: [qt-base, qt]
       rpc: [libtirpc]
       scalapack: [netlib-scalapack, amdscalapack]
       sycl: [hipsycl]
@@ -63,48 +56,9 @@ packages:
       tbb: [intel-tbb]
       unwind: [libunwind]
       uuid: [util-linux-uuid, libuuid]
-      wasi-sdk: [wasi-sdk-prebuilt]
-      xkbdata-api: [xkeyboard-config, xkbdata]
       xxd: [xxd-standalone, vim]
       yacc: [bison, byacc]
       ziglang: [zig]
-      zlib-api: [zlib-ng+compat, zlib]
     permissions:
       read: world
       write: user
-  cce:
-    buildable: false
-  cray-fftw:
-    buildable: false
-  cray-libsci:
-    buildable: false
-  cray-mpich:
-    buildable: false
-  cray-mvapich2:
-    buildable: false
-  cray-pmi:
-    buildable: false
-  egl:
-    buildable: false
-  essl:
-    buildable: false
-  fj:
-    buildable: false
-  fujitsu-mpi:
-    buildable: false
-  fujitsu-ssl2:
-    buildable: false
-  glibc:
-    buildable: false
-  hpcx-mpi:
-    buildable: false
-  iconv:
-    prefer: [libiconv]
-  mpt:
-    buildable: false
-  musl:
-    buildable: false
-  spectrum-mpi:
-    buildable: false
-  xl:
-    buildable: false

etc/spack/defaults/windows/config.yaml

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

etc/spack/defaults/windows/packages.yaml

@@ -15,13 +15,8 @@
 # -------------------------------------------------------------------------
 packages:
   all:
+    compiler:
+    - msvc
     providers:
-      c : [msvc]
-      cxx: [msvc]
       mpi: [msmpi]
       gl: [wgl]
-  mpi:
-    require:
-    - one_of: [msmpi]
-  msvc:
-    buildable: false

lib/spack/docs/.gitignore

@@ -1,3 +1,4 @@
+package_list.html
 command_index.rst
 spack*.rst
 llnl*.rst

lib/spack/docs/_pygments/style.py

@@ -1,4 +1,5 @@
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

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

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -44,8 +45,7 @@ Listing available packages
 
 To install software with Spack, you need to know what software is
 available.  You can see a list of available package names at the
-`packages.spack.io <https://packages.spack.io>`_ website, or
+:ref:`package-list` webpage, or using the ``spack list`` command.
-using the ``spack list`` command.
 
 .. _cmd-spack-list:
 
@@ -60,7 +60,7 @@ can install:
    :ellipsis: 10
 
 There are thousands of them, so we've truncated the output above, but you
-can find a `full list here <https://packages.spack.io>`_.
+can find a :ref:`full list here <package-list>`.
 Packages are listed by name in alphabetical order.
 A pattern to match with no wildcards, ``*`` or ``?``,
 will be treated as though it started and ended with
@@ -864,7 +864,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:
 
@@ -958,86 +958,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>`.
+We'll learn more about Spack's spec syntax in the next section.
-
-
-.. _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.
 
 
 .. _sec-specs:
@@ -1174,17 +1095,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:
@@ -1208,9 +1118,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``,
@@ -1222,10 +1129,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``
@@ -1291,61 +1194,55 @@ based on site policies.
 Variants
 ^^^^^^^^
 
-Variants are named options associated with a particular package and are
+Variants are named options associated with a particular package. They are
-typically used to enable or disable certain features at build time. They
+optional, as each package must provide default values for each variant it
-are optional, as each package must provide default values for each variant
+makes available. Variants can be specified using
-it makes available.
+a flexible parameter syntax ``name=<value>``. For example,
-
+``spack install mercury debug=True`` will install mercury built with debug
-The names of variants available for a particular package depend on
+flags. The names of particular variants available for a package depend on
 what was provided by the package author. ``spack info <package>`` will
 provide information on what build variants are available.
 
-There are different types of variants:
+For compatibility with earlier versions, variants which happen to be
+boolean in nature can be specified by a syntax that represents turning
+options on and off. For example, in the previous spec we could have
+supplied ``mercury +debug`` with the same effect of enabling the debug
+compile time option for the libelf package.
 
-1. Boolean variants. Typically used to enable or disable a feature at
+Depending on the package a variant may have any default value.  For
-   compile time. For example, a package might have a ``debug`` variant that
+``mercury`` here, ``debug`` is ``False`` by default, and we turned it on
-   can be explicitly enabled with ``+debug`` and disabled with ``~debug``.
+with ``debug=True`` or ``+debug``.  If a variant is ``True`` by default
-2. Single-valued variants. Often used to set defaults. For example, a package
+you can turn it off by either adding ``-name`` or ``~name`` to the spec.
-   might have a ``compression`` variant that determines the default
-   compression algorithm, which users could set to ``compression=gzip`` or
-   ``compression=zstd``.
-3. Multi-valued variants. A package might have a ``fabrics`` variant that
-   determines which network fabrics to support. Users could set this to
-   ``fabrics=verbs,ofi`` to enable both InfiniBand verbs and OpenFabrics
-   interfaces. The values are separated by commas.
 
-   The meaning of ``fabrics=verbs,ofi`` is to enable *at least* the specified
+There are two syntaxes here because, depending on context, ``~`` and
-   fabrics, but other fabrics may be enabled as well. If the intent is to
+``-`` may mean different things.  In most shells, the following will
-   enable *only* the specified fabrics, then the ``fabrics:=verbs,ofi``
+result in the shell performing home directory substitution:
-   syntax should be used with the ``:=`` operator.
 
-.. note::
+.. code-block:: sh
 
-   In certain shells, the the ``~`` character is expanded to the home
+   mpileaks ~debug   # shell may try to substitute this!
-   directory. To avoid these issues, avoid whitespace between the package
+   mpileaks~debug    # use this instead
-   name and the variant:
 
-   .. code-block:: sh
+If there is a user called ``debug``, the ``~`` will be incorrectly
+expanded.  In this situation, you would want to write ``libelf
+-debug``.  However, ``-`` can be ambiguous when included after a
+package name without spaces:
 
-      mpileaks ~debug   # shell may try to substitute this!
+.. code-block:: sh
-      mpileaks~debug    # use this instead
 
-   Alternatively, you can use the ``-`` character to disable a variant,
+   mpileaks-debug     # wrong!
-   but be aware that this requires a space between the package name and
+   mpileaks -debug    # right
-   the variant:
 
-   .. code-block:: sh
+Spack allows the ``-`` character to be part of package names, so the
+above will be interpreted as a request for the ``mpileaks-debug``
+package, not a request for ``mpileaks`` built without ``debug``
+options.  In this scenario, you should write ``mpileaks~debug`` to
+avoid ambiguity.
 
-      mpileaks-debug     # wrong: refers to a package named "mpileaks-debug"
+When spack normalizes specs, it prints them out with no spaces boolean
-      mpileaks -debug    # right: refers to a package named mpileaks with debug disabled
+variants using the backwards compatibility syntax and uses only ``~``
-
+for disabled boolean variants.  The ``-`` and spaces on the command
-   As a last resort, ``debug=False`` can also be used to disable a boolean variant.
+line are provided for convenience and legibility.
-
-
-
-"""""""""""""""""""""""""""""""""""
-Variant propagation to dependencies
-"""""""""""""""""""""""""""""""""""
 
 Spack allows variants to propagate their value to the package's
 dependency by using ``++``, ``--``, and ``~~`` for boolean variants.
@@ -1364,10 +1261,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
 ^^^^^^^^^^^^^^
@@ -1415,29 +1308,27 @@ that executables will run without the need to set ``LD_LIBRARY_PATH``.
 
 .. code-block:: yaml
 
-  packages:
+  compilers:
-    gcc:
+    - compiler:
-      externals:
+        spec: gcc@4.9.3
-      - spec: gcc@4.9.3
+        paths:
-        prefix: /opt/gcc
+          cc: /opt/gcc/bin/gcc
-        extra_attributes:
+          c++: /opt/gcc/bin/g++
-          compilers:
+          f77: /opt/gcc/bin/gfortran
-            c: /opt/gcc/bin/gcc
+          fc: /opt/gcc/bin/gfortran
-            cxx: /opt/gcc/bin/g++
+        environment:
-            fortran: /opt/gcc/bin/gfortran
+          unset:
-          environment:
+            - BAD_VARIABLE
-            unset:
+          set:
-              - BAD_VARIABLE
+            GOOD_VARIABLE_NUM: 1
-            set:
+            GOOD_VARIABLE_STR: good
-              GOOD_VARIABLE_NUM: 1
+          prepend_path:
-              GOOD_VARIABLE_STR: good
+            PATH: /path/to/binutils
-            prepend_path:
+          append_path:
-              PATH: /path/to/binutils
+            LD_LIBRARY_PATH: /opt/gcc/lib
-            append_path:
+        extra_rpaths:
-              LD_LIBRARY_PATH: /opt/gcc/lib
+        - /path/to/some/compiler/runtime/directory
-          extra_rpaths:
+        - /path/to/some/other/compiler/runtime/directory
-          - /path/to/some/compiler/runtime/directory
-          - /path/to/some/other/compiler/runtime/directory
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^
@@ -1455,12 +1346,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:
 
@@ -1624,30 +1525,6 @@ any MPI implementation will do.  If another package depends on
 error.  Likewise, if you try to plug in some package that doesn't
 provide MPI, Spack will raise an error.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Explicit binding of virtual dependencies
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-There are packages that provide more than just one virtual dependency. When interacting with them, users
-might want to utilize just a subset of what they could provide, and use other providers for virtuals they
-need.
-
-It is possible to be more explicit and tell Spack which dependency should provide which virtual, using a
-special syntax:
-
-.. code-block:: console
-
-   $ spack spec strumpack ^[virtuals=mpi] intel-parallel-studio+mkl ^[virtuals=lapack] openblas
-
-Concretizing the spec above produces the following DAG:
-
-.. figure:: images/strumpack_virtuals.svg
-   :scale: 60 %
-   :align: center
-
-where ``intel-parallel-studio`` *could* provide ``mpi``, ``lapack``, and ``blas`` but is used only for the former. The ``lapack``
-and ``blas`` dependencies are satisfied by ``openblas``.
-
 ^^^^^^^^^^^^^^^^^^^^^^^^
 Specifying Specs by Hash
 ^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1769,24 +1646,19 @@ Verifying installations
 The ``spack verify`` command can be used to verify the validity of
 Spack-installed packages any time after installation.
 
-
-^^^^^^^^^^^^^^^^^^^^^^^^^
-``spack verify manifest``
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
 At installation time, Spack creates a manifest of every file in the
 installation prefix. For links, Spack tracks the mode, ownership, and
 destination. For directories, Spack tracks the mode, and
 ownership. For files, Spack tracks the mode, ownership, modification
-time, hash, and size. The ``spack verify manifest`` command will check,
+time, hash, and size. The Spack verify command will check, for every
-for every file in each package, whether any of those attributes have
+file in each package, whether any of those attributes have changed. It
-changed. It will also check for newly added files or deleted files from
+will also check for newly added files or deleted files from the
-the installation prefix. Spack can either check all installed packages
+installation prefix. Spack can either check all installed packages
 using the `-a,--all` or accept specs listed on the command line to
 verify.
 
-The ``spack verify manifest`` command can also verify for individual files
+The ``spack verify`` command can also verify for individual files that
-that they haven't been altered since installation time. If the given file
+they haven't been altered since installation time. If the given file
 is not in a Spack installation prefix, Spack will report that it is
 not owned by any package. To check individual files instead of specs,
 use the ``-f,--files`` option.
@@ -1801,21 +1673,164 @@ 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.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-``spack verify libraries``
-^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The ``spack verify libraries`` command can be used to verify that packages
+.. _extensions:
-do not have accidental system dependencies. This command scans the install
-prefixes of packages for executables and shared libraries, and resolves
-their needed libraries in their RPATHs. When needed libraries cannot be
-located, an error is reported. This typically indicates that a package
-was linked against a system library, instead of a library provided by
-a Spack package.
 
-This verification can also be enabled as a post-install hook by setting
+---------------------------
-``config:shared_linking:missing_library_policy`` to ``error`` or ``warn``
+Extensions & Python support
-in :ref:`config.yaml <config-yaml>`.
+---------------------------
+
+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

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -47,10 +48,14 @@ Here is an example where a build cache is created in a local directory named
 
 .. code-block:: console
 
-    $ spack buildcache push ./spack-cache ninja
+    $ spack buildcache push --allow-root ./spack-cache ninja
     ==> Pushing binary packages to file:///home/spackuser/spack/spack-cache/build_cache
 
-Note that ``ninja`` must be installed locally for this to work.
+Not that ``ninja`` must be installed locally for this to work.
+
+We're using the ``--allow-root`` flag to tell Spack that is OK when any of
+the binaries we're pushing contain references to the local Spack install
+directory.
 
 Once you have a build cache, you can add it as a mirror, discussed next.
 
@@ -142,7 +147,7 @@ and then install from it exclusively, you would do:
 
     $ spack mirror add E4S https://cache.e4s.io
     $ spack buildcache keys --install --trust
-    $ spack install --use-buildcache only <package>
+    $ spack install --use-buildache only <package>
 
 We use ``--install`` and ``--trust`` to say that we are installing keys to our
 keyring, and trusting all downloaded keys.
@@ -152,186 +157,18 @@ keyring, and trusting all downloaded keys.
 List of popular build caches
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-* `Extreme-scale Scientific Software Stack (E4S) <https://e4s-project.github.io/>`_: `build cache <https://oaciss.uoregon.edu/e4s/inventory.html>`_'
+* `Extreme-scale Scientific Software Stack (E4S) <https://e4s-project.github.io/>`_: `build cache <https://oaciss.uoregon.edu/e4s/inventory.html>`_
 
--------------------
-Build cache signing
--------------------
-
-By default, Spack will add a cryptographic signature to each package pushed to
-a build cache, and verifies the signature when installing from a build cache.
-
-Keys for signing can be managed with the :ref:`spack gpg <cmd-spack-gpg>` command,
-as well as ``spack buildcache keys`` as mentioned above.
-
-You can disable signing when pushing with ``spack buildcache push --unsigned``,
-and disable verification when installing from any build cache with
-``spack install --no-check-signature``.
-
-Alternatively, signing and verification can be enabled or disabled on a per build cache
-basis:
-
-.. code-block:: console
-
-    $ spack mirror add --signed <name> <url>  # enable signing and verification
-    $ spack mirror add --unsigned <name> <url>  # disable signing and verification
-
-    $ spack mirror set --signed <name>  # enable signing and verification for an existing mirror
-    $ spack mirror set --unsigned <name>  # disable signing and verification for an existing mirror
-
-Or you can directly edit the ``mirrors.yaml`` configuration file:
-
-.. code-block:: yaml
-
-    mirrors:
-      <name>:
-        url: <url>
-        signed: false # disable signing and verification
-
-See also :ref:`mirrors`.
 
 ----------
 Relocation
 ----------
 
-When using buildcaches across different machines, it is likely that the install
+Initial build and later installation do not necessarily happen at the same
-root will be different from the one used to build the binaries.
+location. Spack provides a relocation capability and corrects for RPATHs and
-
+non-relocatable scripts. However, many packages compile paths into binary
-To address this issue, Spack automatically relocates all paths encoded in binaries
+artifacts directly. In such cases, the build instructions of this package would
-and scripts to their new location upon install.
+need to be adjusted for better re-locatability.
-
-Note that there are some cases where this is not possible: if binaries are built in
-a relatively short path, and then installed to a longer path, there may not be enough
-space in the binary to encode the new path. In this case, Spack will fail to install
-the package from the build cache, and a source build is required.
-
-To reduce the likelihood of this happening, it is highly recommended to add padding to
-the install root during the build, as specified in the :ref:`config <config-yaml>`
-section of the configuration:
-
-.. code-block:: yaml
-
-   config:
-     install_tree:
-       root: /opt/spack
-       padded_length: 128
-
-
-.. _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
------------------------------------------
-
-Spack can also use OCI or Docker V2 registries such as Dockerhub, Quay.io,
-Github Packages, GitLab Container Registry, JFrog Artifactory, and others
-as build caches. This is a convenient way to share binaries using public
-infrastructure, or to cache Spack built binaries in Github Actions and
-GitLab CI.
-
-To get started, configure an OCI mirror using ``oci://`` as the scheme,
-and optionally specify variables that hold the username and password (or
-personal access token) for the registry:
-
-.. code-block:: console
-
-    $ spack mirror add --oci-username-variable REGISTRY_USER \
-                       --oci-password-variable REGISTRY_TOKEN \
-                       my_registry oci://example.com/my_image
-
-Spack follows the naming conventions of Docker, with Dockerhub as the default
-registry. To use Dockerhub, you can omit the registry domain:
-
-.. code-block:: console
-
-    $ spack mirror add ... my_registry oci://username/my_image
-
-From here, you can use the mirror as any other build cache:
-
-.. code-block:: console
-
-    $ export REGISTRY_USER=...
-    $ export REGISTRY_TOKEN=...
-    $ spack buildcache push my_registry <specs...>  # push to the registry
-    $ spack install <specs...>  # or install from the registry
-
-A unique feature of buildcaches on top of OCI registries is that it's incredibly
-easy to generate get a runnable container image with the binaries installed. This
-is a great way to make applications available to users without requiring them to
-install Spack -- all you need is Docker, Podman or any other OCI-compatible container
-runtime.
-
-To produce container images, all you need to do is add the ``--base-image`` flag
-when pushing to the build cache:
-
-.. code-block:: console
-
-    $ spack buildcache push --base-image ubuntu:20.04 my_registry ninja
-    Pushed to example.com/my_image:ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spack
-
-    $ docker run -it example.com/my_image:ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spack
-    root@e4c2b6f6b3f4:/# ninja --version
-    1.11.1
-
-If ``--base-image`` is not specified, distroless images are produced. In practice,
-you won't be able to run these as containers, since they don't come with libc and
-other system dependencies. However, they are still compatible with tools like
-``skopeo``, ``podman``, and ``docker`` for pulling and pushing.
-
-.. note::
-    The docker ``overlayfs2`` storage driver is limited to 128 layers, above which a
-    ``max depth exceeded`` error may be produced when pulling the image. There
-    are `alternative drivers <https://docs.docker.com/storage/storagedriver/>`_.
-
-------------------------------------
-Spack build cache for GitHub Actions
-------------------------------------
-
-To significantly speed up Spack in GitHub Actions, binaries can be cached in
-GitHub Packages. This service is an OCI registry that can be linked to a GitHub
-repository.
-
-Spack offers a public build cache for GitHub Actions with a set of common packages,
-which lets you get started quickly. See the following resources for more information:
-
-* `spack/setup-spack <https://github.com/spack/setup-spack>`_ for setting up Spack in GitHub
-  Actions
-* `spack/github-actions-buildcache <https://github.com/spack/github-actions-buildcache>`_ for
-  more details on the public build cache
 
 .. _cmd-spack-buildcache:
 

lib/spack/docs/bootstrapping.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -31,14 +32,9 @@ can't be found. You can readily check if any prerequisite for using Spack is mis
 
    Spack will take care of bootstrapping any missing dependency marked as [B]. Dependencies marked as [-] are instead required to be found on the system.
 
-   % echo $?
-   1
-
 In the case of the output shown above Spack detected that both ``clingo`` and ``gnupg``
 are missing and it's giving detailed information on why they are needed and whether
-they can be bootstrapped. The return code of this command summarizes the results, if any
+they can be bootstrapped. Running a command that concretize a spec, like:
-dependencies are missing the return code is ``1``, otherwise ``0``. Running a command that
-concretizes a spec, like:
 
 .. code-block:: console
 
@@ -48,7 +44,7 @@ concretizes a spec, like:
    ==> Installing "clingo-bootstrap@spack%apple-clang@12.0.0~docs~ipo+python build_type=Release arch=darwin-catalina-x86_64" from a buildcache
    [ ... ]
 
-automatically triggers the bootstrapping of clingo from pre-built binaries as expected.
+triggers the bootstrapping of clingo from pre-built binaries as expected.
 
 Users can also bootstrap all the dependencies needed by Spack in a single command, which
 might be useful to setup containers or other similar environments:
@@ -86,7 +82,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 ------------------
@@ -100,7 +96,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
 
@@ -170,8 +166,8 @@ bootstrapping.
    To register the mirror on the platform where it's supposed to be used run the following command(s):
      % spack bootstrap add --trust local-sources /opt/bootstrap/metadata/sources
      % spack bootstrap add --trust local-binaries /opt/bootstrap/metadata/binaries
-     % spack buildcache update-index /opt/bootstrap/bootstrap_cache
+
 
 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

@@ -1,113 +1,275 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
+.. _build-settings:
+
+================================
+Package Settings (packages.yaml)
+================================
+
+Spack allows you to customize how your software is built through the
+``packages.yaml`` file.  Using it, you can make Spack prefer particular
+implementations of virtual dependencies (e.g., MPI or BLAS/LAPACK),
+or you can make it prefer to build with particular compilers.  You can
+also tell Spack to use *external* software installations already
+present on your system.
+
+At a high level, the ``packages.yaml`` file is structured like this:
+
+.. code-block:: yaml
+
+   packages:
+     package1:
+       # settings for package1
+     package2:
+       # settings for package2
+     # ...
+     all:
+       # settings that apply to all packages.
+
+So you can either set build preferences specifically for *one* package,
+or you can specify that certain settings should apply to *all* packages.
+The types of settings you can customize are described in detail below.
+
+Spack's build defaults are in the default
+``etc/spack/defaults/packages.yaml`` file.  You can override them in
+``~/.spack/packages.yaml`` or ``etc/spack/packages.yaml``. For more
+details on how this works, see :ref:`configuration-scopes`.
+
+.. _sec-external-packages:
+
+-----------------
+External Packages
+-----------------
+
+Spack can be configured to use externally-installed
+packages rather than building its own packages. This may be desirable
+if machines ship with system packages, such as a customized MPI
+that should be used instead of Spack building its own MPI.
+
+External packages are configured through the ``packages.yaml`` file.
+Here's an example of an external configuration:
+
+.. code-block:: yaml
+
+   packages:
+     openmpi:
+       externals:
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.4.3
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
+         prefix: /opt/openmpi-1.4.3-debug
+       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.6.5-intel
+
+This example lists three installations of OpenMPI, one built with GCC,
+one built with GCC and debug information, and another built with Intel.
+If Spack is asked to build a package that uses one of these MPIs as a
+dependency, it will use the pre-installed OpenMPI in
+the given directory. Note that the specified path is the top-level
+install prefix, not the ``bin`` subdirectory.
+
+``packages.yaml`` can also be used to specify modules to load instead
+of the installation prefixes.  The following example says that module
+``CMake/3.7.2`` provides cmake version 3.7.2.
+
+.. code-block:: yaml
+
+   cmake:
+     externals:
+     - spec: cmake@3.7.2
+       modules:
+       - CMake/3.7.2
+
+Each ``packages.yaml`` begins with a ``packages:`` attribute, followed
+by a list of package names.  To specify externals, add an ``externals:``
+attribute under the package name, which lists externals.
+Each external should specify a ``spec:`` string that should be as
+well-defined as reasonably possible.  If a
+package lacks a spec component, such as missing a compiler or
+package version, then Spack will guess the missing component based
+on its most-favored packages, and it may guess incorrectly.
+
+Each package version and compiler listed in an external should
+have entries in Spack's packages and compiler configuration, even
+though the package and compiler may not ever be built.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Prevent packages from being built from sources
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Adding an external spec in ``packages.yaml`` allows Spack to use an external location,
+but it does not prevent Spack from building packages from sources. In the above example,
+Spack might choose for many valid reasons to start building and linking with the
+latest version of OpenMPI rather than continue using the pre-installed OpenMPI versions.
+
+To prevent this, the ``packages.yaml`` configuration also allows packages
+to be flagged as non-buildable.  The previous example could be modified to
+be:
+
+.. code-block:: yaml
+
+   packages:
+     openmpi:
+       externals:
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.4.3
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
+         prefix: /opt/openmpi-1.4.3-debug
+       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.6.5-intel
+       buildable: False
+
+The addition of the ``buildable`` flag tells Spack that it should never build
+its own version of OpenMPI from sources, and it will instead always rely on a pre-built
+OpenMPI.
+
+.. note::
+
+   If ``concretizer:reuse`` is on (see :ref:`concretizer-options` for more information on that flag)
+   pre-built specs include specs already available from a local store, an upstream store, a registered
+   buildcache or specs marked as externals in ``packages.yaml``. If ``concretizer:reuse`` is off, only
+   external specs in ``packages.yaml`` are included in the list of pre-built specs.
+
+If an external module is specified as not buildable, then Spack will load the
+external module into the build environment which can be used for linking.
+
+The ``buildable`` does not need to be paired with external packages.
+It could also be used alone to forbid packages that may be
+buggy or otherwise undesirable.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Non-buildable virtual packages
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Virtual packages in Spack can also be specified as not buildable, and
+external implementations can be provided. In the example above,
+OpenMPI is configured as not buildable, but Spack will often prefer
+other MPI implementations over the externally available OpenMPI. Spack
+can be configured with every MPI provider not buildable individually,
+but more conveniently:
+
+.. code-block:: yaml
+
+   packages:
+     mpi:
+       buildable: False
+     openmpi:
+       externals:
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.4.3
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
+         prefix: /opt/openmpi-1.4.3-debug
+       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.6.5-intel
+
+Spack can then use any of the listed external implementations of MPI
+to satisfy a dependency, and will choose depending on the compiler and
+architecture.
+
+In cases where the concretizer is configured to reuse specs, and other ``mpi`` providers
+(available via stores or buildcaches) are not wanted, Spack can be configured to require
+specs matching only the available externals:
+
+.. code-block:: yaml
+
+   packages:
+     mpi:
+       buildable: False
+       require:
+       - one_of: [
+           "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64",
+           "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug",
+           "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
+         ]
+     openmpi:
+       externals:
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.4.3
+       - spec: "openmpi@1.4.3%gcc@4.4.7 arch=linux-debian7-x86_64+debug"
+         prefix: /opt/openmpi-1.4.3-debug
+       - spec: "openmpi@1.6.5%intel@10.1 arch=linux-debian7-x86_64"
+         prefix: /opt/openmpi-1.6.5-intel
+
+This configuration prevents any spec using MPI and originating from stores or buildcaches to be reused,
+unless it matches the requirements under ``packages:mpi:require``. For more information on requirements see
+:ref:`package-requirements`.
+
+.. _cmd-spack-external-find:
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Automatically Find External Packages
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can run the :ref:`spack external find <spack-external-find>` command
+to search for system-provided packages and add them to ``packages.yaml``.
+After running this command your ``packages.yaml`` may include new entries:
+
+.. code-block:: yaml
+
+   packages:
+     cmake:
+       externals:
+       - spec: cmake@3.17.2
+         prefix: /usr
+
+Generally this is useful for detecting a small set of commonly-used packages;
+for now this is generally limited to finding build-only dependencies.
+Specific limitations include:
+
+* Packages are not discoverable by default: For a package to be
+  discoverable with ``spack external find``, it needs to add special
+  logic. See :ref:`here <make-package-findable>` for more details.
+* The logic does not search through module files, it can only detect
+  packages with executables defined in ``PATH``; you can help Spack locate
+  externals which use module files by loading any associated modules for
+  packages that you want Spack to know about before running
+  ``spack external find``.
+* Spack does not overwrite existing entries in the package configuration:
+  If there is an external defined for a spec at any configuration scope,
+  then Spack will not add a new external entry (``spack config blame packages``
+  can help locate all external entries).
 
 .. _concretizer-options:
 
-==========================================
+----------------------
-Concretization Settings (concretizer.yaml)
+Concretizer options
-==========================================
+----------------------
 
-The ``concretizer.yaml`` configuration file allows to customize aspects of the
+``packages.yaml`` gives the concretizer preferences for specific packages,
-algorithm used to select the dependencies you install. The default configuration
+but you can also use ``concretizer.yaml`` to customize aspects of the
-is the following:
+algorithm it uses to select the dependencies you install:
 
 .. literalinclude:: _spack_root/etc/spack/defaults/concretizer.yaml
    :language: yaml
 
---------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Reuse already installed packages
---------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The ``reuse`` attribute controls how aggressively Spack reuses binary packages during concretization. The
+The ``reuse`` attribute controls whether Spack will prefer to use installed packages (``true``), or
-attribute can either be a single value, or an object for more complex configurations.
+whether it will do a "fresh" installation and prefer the latest settings from
-
+``package.py`` files and ``packages.yaml`` (``false``).
-In the former case ("single value") it allows Spack to:
+You can use:
-
-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:
 
 .. 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: true`` is the default.
 
-.. seealso::
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-   FAQ: :ref:`Why does Spack pick particular versions and variants? <faq-concretizer-precedence>`
-
-------------------------------------------
 Selection of the target microarchitectures
-------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The options under the ``targets`` attribute control which targets are considered during a solve.
 Currently the options in this section are only configurable from the ``concretizer.yaml`` file
@@ -140,131 +302,321 @@ microarchitectures considered during the solve are constrained to be compatible
 host Spack is currently running on. For instance, if this option is set to ``true``, a
 user cannot concretize for ``target=icelake`` while running on an Haswell node.
 
----------------
+.. _package-requirements:
-Duplicate nodes
----------------
 
-The ``duplicates`` attribute controls whether the DAG can contain multiple configurations of
+--------------------
-the same package. This is mainly relevant for build dependencies, which may have their version
+Package Requirements
-pinned by some nodes, and thus be required at different versions by different nodes in the same
+--------------------
-DAG.
 
-The ``strategy`` option controls how the solver deals with duplicates. If the value is ``none``,
+Spack can be configured to always use certain compilers, package
-then a single configuration per package is allowed in the DAG. This means, for instance, that only
+versions, and variants during concretization through package
-a single ``cmake`` or a single ``py-setuptools`` version is allowed. The result would be a slightly
+requirements.
-faster concretization, at the expense of making a few specs unsolvable.
 
-If the value is ``minimal`` Spack will allow packages tagged as ``build-tools`` to have duplicates.
+Package requirements are useful when you find yourself repeatedly
-This allows, for instance, to concretize specs whose nodes require different, and incompatible, ranges
+specifying the same constraints on the command line, and wish that
-of some build tool. For instance, in the figure below the latest `py-shapely` requires a newer `py-setuptools`,
+Spack respects these constraints whether you mention them explicitly
-while `py-numpy` still needs an older version:
+or not. Another use case is specifying constraints that should apply
+to all root specs in an environment, without having to repeat the
+constraint everywhere.
 
-.. figure::  images/shapely_duplicates.svg
+Apart from that, requirements config is more flexible than constraints
-   :scale: 70 %
+on the command line, because it can specify constraints on packages
-   :align: center
+*when they occur* as a dependency. In contrast, on the command line it
+is not possible to specify constraints on dependencies while also keeping
+those dependencies optional.
 
-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``.
+Requirements syntax
+^^^^^^^^^^^^^^^^^^^
 
---------
+The package requirements configuration is specified in ``packages.yaml``,
-Splicing
+keyed by package name and expressed using the Spec syntax. In the simplest
---------
+case you can specify attributes that you always want the package to have
-
+by providing a single spec string to ``require``:
-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:
+   packages:
-     splice:
+     libfabric:
-       explicit:
+       require: "@1.13.2"
-       - target: mpi
-         replacement: mpich/abcdef
-         transitive: false
 
-.. warning::
+In the above example, ``libfabric`` will always build with version 1.13.2. If you
-
+need to compose multiple configuration scopes ``require`` accepts a list of
-   When configuring an explicit splice, you as the user take on the
+strings:
-   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:
+   packages:
-     splice:
+     libfabric:
-       automatic: True
+       require:
+       - "@1.13.2"
+       - "%gcc"
 
-Packages can include ABI-compatibility information using the
+In this case ``libfabric`` will always build with version 1.13.2 **and** using GCC
-``can_splice`` directive. See :ref:`the packaging
+as a compiler.
-guide<abi_compatibility>` for instructions on specifying ABI
+
-compatibility using the ``can_splice`` directive.
+For more complex use cases, require accepts also a list of objects. These objects
+must have either a ``any_of`` or a ``one_of`` field, containing a list of spec strings,
+and they can optionally have a ``when`` and a ``message`` attribute:
+
+.. code-block:: yaml
+
+   packages:
+     openmpi:
+       require:
+       - any_of: ["@4.1.5", "%gcc"]
+         message: "in this example only 4.1.5 can build with other compilers"
+
+``any_of`` is a list of specs. One of those specs must be satisfied
+and it is also allowed for the concretized spec to match more than one.
+In the above example, that means you could build ``openmpi@4.1.5%gcc``,
+``openmpi@4.1.5%clang`` or ``openmpi@3.9%gcc``, but
+not ``openmpi@3.9%clang``.
+
+If a custom message is provided, and the requirement is not satisfiable,
+Spack will print the custom error message:
+
+.. code-block:: console
+
+   $ spack spec openmpi@3.9%clang
+   ==> Error: in this example only 4.1.5 can build with other compilers
+
+We could express a similar requirement using the ``when`` attribute:
+
+.. code-block:: yaml
+
+   packages:
+     openmpi:
+       require:
+       - any_of: ["%gcc"]
+         when: "@:4.1.4"
+         message: "in this example only 4.1.5 can build with other compilers"
+
+In the example above, if the version turns out to be 4.1.4 or less, we require the compiler to be GCC.
+For readability, Spack also allows a ``spec`` key accepting a string when there is only a single
+constraint:
+
+.. code-block:: yaml
+
+   packages:
+     openmpi:
+       require:
+       - spec: "%gcc"
+         when: "@:4.1.4"
+         message: "in this example only 4.1.5 can build with other compilers"
+
+This code snippet and the one before it are semantically equivalent.
+
+Finally, instead of ``any_of`` you can use ``one_of`` which also takes a list of specs. The final
+concretized spec must match one and only one of them:
+
+.. code-block:: yaml
+
+   packages:
+     mpich:
+       require:
+       - one_of: ["+cuda", "+rocm"]
+
+In the example above, that means you could build ``mpich+cuda`` or ``mpich+rocm`` but not ``mpich+cuda+rocm``.
 
 .. note::
 
-   The ``can_splice`` directive is experimental and may be changed in
+   For ``any_of`` and ``one_of``, the order of specs indicates a
-   future versions.
+   preference: items that appear earlier in the list are preferred
+   (note that these preferences can be ignored in favor of others).
 
-When automatic splicing is enabled, the concretizer will combine any
+.. note::
-number of ABI-compatible specs if possible to reuse installed packages
+
-and packages available from binary caches. The end result of these
+   When using a conditional requirement, Spack is allowed to actively avoid the triggering
-specs is equivalent to a series of transitive/intransitive splices,
+   condition (the ``when=...`` spec) if that leads to a concrete spec with better scores in
-but the series may be non-obvious.
+   the optimization criteria. To check the current optimization criteria and their
+   priorities you can run ``spack solve zlib``.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Setting default requirements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can also set default requirements for all packages under ``all``
+like this:
+
+.. code-block:: yaml
+
+   packages:
+     all:
+       require: '%clang'
+
+which means every spec will be required to use ``clang`` as a compiler.
+
+Note that in this case ``all`` represents a *default set of requirements* -
+if there are specific package requirements, then the default requirements
+under ``all`` are disregarded. For example, with a configuration like this:
+
+.. code-block:: yaml
+
+   packages:
+     all:
+       require: '%clang'
+     cmake:
+       require: '%gcc'
+
+Spack requires ``cmake`` to use ``gcc`` and all other nodes (including ``cmake``
+dependencies) to use ``clang``.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Setting requirements on virtual specs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A requirement on a virtual spec applies whenever that virtual is present in the DAG.
+This can be useful for fixing which virtual provider you want to use:
+
+.. code-block:: yaml
+
+   packages:
+     mpi:
+       require: 'mvapich2 %gcc'
+
+With the configuration above the only allowed ``mpi`` provider is ``mvapich2 %gcc``.
+
+Requirements on the virtual spec and on the specific provider are both applied, if
+present. For instance with a configuration like:
+
+.. code-block:: yaml
+
+   packages:
+     mpi:
+       require: 'mvapich2 %gcc'
+     mvapich2:
+       require: '~cuda'
+
+you will use ``mvapich2~cuda %gcc`` as an ``mpi`` provider.
+
+.. _package-preferences:
+
+-------------------
+Package Preferences
+-------------------
+
+In some cases package requirements can be too strong, and package
+preferences are the better option. Package preferences do not impose
+constraints on packages for particular versions or variants values,
+they rather only set defaults -- the concretizer is free to change
+them if it must due to other constraints. Also note that package
+preferences are of lower priority than reuse of already installed
+packages.
+
+Here's an example ``packages.yaml`` file that sets preferred packages:
+
+.. code-block:: yaml
+
+   packages:
+     opencv:
+       compiler: [gcc@4.9]
+       variants: +debug
+     gperftools:
+       version: [2.2, 2.4, 2.3]
+     all:
+       compiler: [gcc@4.4.7, 'gcc@4.6:', intel, clang, pgi]
+       target: [sandybridge]
+       providers:
+         mpi: [mvapich2, mpich, openmpi]
+
+At a high level, this example is specifying how packages are preferably
+concretized.  The opencv package should prefer using GCC 4.9 and
+be built with debug options.  The gperftools package should prefer version
+2.2 over 2.4.  Every package on the system should prefer mvapich2 for
+its MPI and GCC 4.4.7 (except for opencv, which overrides this by preferring GCC 4.9).
+These options are used to fill in implicit defaults.  Any of them can be overwritten
+on the command line if explicitly requested.
+
+Package preferences accept the follow keys or components under
+the specific package (or ``all``) section: ``compiler``, ``variants``,
+``version``, ``providers``, and ``target``.  Each component has an
+ordered list of spec ``constraints``, with earlier entries in the
+list being preferred over later entries.
+
+Sometimes a package installation may have constraints that forbid
+the first concretization rule, in which case Spack will use the first
+legal concretization rule.  Going back to the example, if a user
+requests gperftools 2.3 or later, then Spack will install version 2.4
+as the 2.4 version of gperftools is preferred over 2.3.
+
+An explicit concretization rule in the preferred section will always
+take preference over unlisted concretizations.  In the above example,
+xlc isn't listed in the compiler list.  Every listed compiler from
+gcc to pgi will thus be preferred over the xlc compiler.
+
+The syntax for the ``provider`` section differs slightly from other
+concretization rules.  A provider lists a value that packages may
+``depends_on`` (e.g, MPI) and a list of rules for fulfilling that
+dependency.
+
+.. _package_permissions:
+
+-------------------
+Package Permissions
+-------------------
+
+Spack can be configured to assign permissions to the files installed
+by a package.
+
+In the ``packages.yaml`` file under ``permissions``, the attributes
+``read``, ``write``, and ``group`` control the package
+permissions. These attributes can be set per-package, or for all
+packages under ``all``. If permissions are set under ``all`` and for a
+specific package, the package-specific settings take precedence.
+
+The ``read`` and ``write`` attributes take one of ``user``, ``group``,
+and ``world``.
+
+.. code-block:: yaml
+
+  packages:
+    all:
+      permissions:
+        write: group
+        group: spack
+    my_app:
+      permissions:
+        read: group
+        group: my_team
+
+The permissions settings describe the broadest level of access to
+installations of the specified packages. The execute permissions of
+the file are set to the same level as read permissions for those files
+that are executable. The default setting for ``read`` is ``world``,
+and for ``write`` is ``user``. In the example above, installations of
+``my_app`` will be installed with user and group permissions but no
+world permissions, and owned by the group ``my_team``. All other
+packages will be installed with user and group write privileges, and
+world read privileges. Those packages will be owned by the group
+``spack``.
+
+The ``group`` attribute assigns a Unix-style group to a package. All
+files installed by the package will be owned by the assigned group,
+and the sticky group bit will be set on the install prefix and all
+directories inside the install prefix. This will ensure that even
+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
+----------------------------
+
+You can assign class-level attributes in the configuration:
+
+.. code-block:: yaml
+
+  packages:
+    mpileaks:
+      # 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
+attributes may be any value parseable by yaml.
+
+These can only be applied to specific packages, not "all" or
+virtual packages.

lib/spack/docs/build_systems.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -63,6 +64,7 @@ on these ideas for each distinct build system that Spack supports:
    build_systems/cudapackage
    build_systems/custompackage
    build_systems/inteloneapipackage
+   build_systems/intelpackage
    build_systems/rocmpackage
    build_systems/sourceforgepackage
 

lib/spack/docs/build_systems/autotoolspackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -126,9 +127,9 @@ check out a commit from the ``master`` branch, you would want to add:
 
 .. code-block:: python
 
-   depends_on("autoconf", type="build", when="@master")
+   depends_on('autoconf', type='build', when='@master')
-   depends_on("automake", type="build", when="@master")
+   depends_on('automake', type='build', when='@master')
-   depends_on("libtool",  type="build", when="@master")
+   depends_on('libtool',  type='build', when='@master')
 
 It is typically redundant to list the ``m4`` macro processor package as a
 dependency, since ``autoconf`` already depends on it.
@@ -144,16 +145,7 @@ example, the ``bash`` shell is used to run the ``autogen.sh`` script.
 .. code-block:: python
 
    def autoreconf(self, spec, prefix):
-       which("bash")("autogen.sh")
+       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
@@ -194,9 +186,9 @@ To opt out of this feature, use the following setting:
 To enable it conditionally on different architectures, define a property and
 make the package depend on ``gnuconfig`` as a build dependency:
 
-.. code-block:: python
+.. code-block
 
-   depends_on("gnuconfig", when="@1.0:")
+   depends_on('gnuconfig', when='@1.0:')
 
    @property
    def patch_config_files(self):
@@ -238,7 +230,7 @@ version, this can be done like so:
 
    @property
    def force_autoreconf(self):
-       return self.version == Version("1.2.3")
+       return self.version == Version('1.2.3')
 
 ^^^^^^^^^^^^^^^^^^^^^^^
 Finding configure flags
@@ -272,9 +264,9 @@ often lists dependencies and the flags needed to locate them. The
 "environment variables" section lists environment variables that the
 build system uses to pass flags to the compiler and linker.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
-Adding flags to configure
+Addings flags to configure
-^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 For most of the flags you encounter, you will want a variant to
 optionally enable/disable them. You can then optionally pass these
@@ -285,26 +277,14 @@ function like so:
 
    def configure_args(self):
        args = []
-       ...
+
-       if self.spec.satisfies("+mpi"):
+       if '+mpi' in self.spec:
-           args.append("--enable-mpi")
+           args.append('--enable-mpi')
        else:
-           args.append("--disable-mpi")
+           args.append('--disable-mpi')
 
        return args
 
-
-Alternatively, you can use the :ref:`enable_or_disable  <autotools_enable_or_disable>` helper:
-
-.. code-block:: python
-
-   def configure_args(self):
-       args = []
-       ...
-       args.extend(self.enable_or_disable("mpi"))
-       return args
-
-
 Note that we are explicitly disabling MPI support if it is not
 requested. This is important, as many Autotools packages will enable
 options by default if the dependencies are found, and disable them
@@ -315,11 +295,9 @@ and `here <https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_depe
 for a rationale as to why these so-called "automagic" dependencies
 are a problem.
 
-.. note::
+By default, Autotools installs packages to ``/usr``. We don't want this,
-
+so Spack automatically adds ``--prefix=/path/to/installation/prefix``
-   By default, Autotools installs packages to ``/usr``. We don't want this,
+to your list of ``configure_args``. You don't need to add this yourself.
-   so Spack automatically adds ``--prefix=/path/to/installation/prefix``
-   to your list of ``configure_args``. You don't need to add this yourself.
 
 ^^^^^^^^^^^^^^^^
 Helper functions
@@ -330,8 +308,6 @@ You may have noticed that most of the Autotools flags are of the form
 ``--without-baz``. Since these flags are so common, Spack provides a
 couple of helper functions to make your life easier.
 
-.. _autotools_enable_or_disable:
-
 """""""""""""""""
 enable_or_disable
 """""""""""""""""
@@ -343,18 +319,11 @@ typically used to enable or disable some feature within the package.
 .. code-block:: python
 
    variant(
-       "memchecker",
+       'memchecker',
        default=False,
-       description="Memchecker support for debugging [degrades performance]"
+       description='Memchecker support for debugging [degrades performance]'
    )
-   ...
+   config_args.extend(self.enable_or_disable('memchecker'))
-
-   def configure_args(self):
-       args = []
-       ...
-       args.extend(self.enable_or_disable("memchecker"))
-
-       return args
 
 In this example, specifying the variant ``+memchecker`` will generate
 the following configuration options:
@@ -374,15 +343,15 @@ the ``with_or_without`` method.
 .. code-block:: python
 
    variant(
-       "schedulers",
+       'schedulers',
        values=disjoint_sets(
-           ("auto",), ("alps", "lsf", "tm", "slurm", "sge", "loadleveler")
+           ('auto',), ('alps', 'lsf', 'tm', 'slurm', 'sge', 'loadleveler')
-       ).with_non_feature_values("auto", "none"),
+       ).with_non_feature_values('auto', 'none'),
        description="List of schedulers for which support is enabled; "
        "'auto' lets openmpi determine",
    )
-   if not spec.satisfies("schedulers=auto"):
+   if 'schedulers=auto' not in spec:
-       config_args.extend(self.with_or_without("schedulers"))
+       config_args.extend(self.with_or_without('schedulers'))
 
 In this example, specifying the variant ``schedulers=slurm,sge`` will
 generate the following configuration options:
@@ -407,16 +376,16 @@ generated, using the ``activation_value`` argument to
 .. code-block:: python
 
    variant(
-      "fabrics",
+      'fabrics',
        values=disjoint_sets(
-           ("auto",), ("psm", "psm2", "verbs", "mxm", "ucx", "libfabric")
+           ('auto',), ('psm', 'psm2', 'verbs', 'mxm', 'ucx', 'libfabric')
-       ).with_non_feature_values("auto", "none"),
+       ).with_non_feature_values('auto', 'none'),
        description="List of fabrics that are enabled; "
        "'auto' lets openmpi determine",
    )
-   if not spec.satisfies("fabrics=auto"):
+   if 'fabrics=auto' not in spec:
-       config_args.extend(self.with_or_without("fabrics",
+       config_args.extend(self.with_or_without('fabrics',
-           activation_value="prefix"))
+           activation_value='prefix'))
 
 ``activation_value`` accepts a callable that generates the configure
 parameter value given the variant value; but the special value
@@ -440,16 +409,16 @@ When Spack variants and configure flags do not correspond one-to-one, the
 
 .. code-block:: python
 
-   variant("debug_tools", default=False)
+   variant('debug_tools', default=False)
-   config_args += self.enable_or_disable("debug-tools", variant="debug_tools")
+   config_args += self.enable_or_disable('debug-tools', variant='debug_tools')
 
 Or when one variant controls multiple flags:
 
 .. code-block:: python
 
-   variant("debug_tools", default=False)
+   variant('debug_tools', default=False)
-   config_args += self.with_or_without("memchecker", variant="debug_tools")
+   config_args += self.with_or_without('memchecker', variant='debug_tools')
-   config_args += self.with_or_without("profiler", variant="debug_tools")
+   config_args += self.with_or_without('profiler', variant='debug_tools')
 
 
 """"""""""""""""""""
@@ -463,8 +432,8 @@ For example:
 
 .. code-block:: python
 
-   variant("profiler", when="@2.0:")
+   variant('profiler', when='@2.0:')
-   config_args += self.with_or_without("profiler")
+   config_args += self.with_or_without('profiler')
 
 will neither add ``--with-profiler`` nor ``--without-profiler`` when the version is
 below ``2.0``.
@@ -483,10 +452,10 @@ the variant values require atypical behavior.
    def with_or_without_verbs(self, activated):
        # Up through version 1.6, this option was named --with-openib.
        # In version 1.7, it was renamed to be --with-verbs.
-       opt = "verbs" if self.spec.satisfies("@1.7:") else "openib"
+       opt = 'verbs' if self.spec.satisfies('@1.7:') else 'openib'
        if not activated:
-           return f"--without-{opt}"
+           return '--without-{0}'.format(opt)
-       return f"--with-{opt}={self.spec['rdma-core'].prefix}"
+       return '--with-{0}={1}'.format(opt, self.spec['rdma-core'].prefix)
 
 Defining ``with_or_without_verbs`` overrides the behavior of a
 ``fabrics=verbs`` variant, changing the configure-time option to
@@ -510,7 +479,7 @@ do this like so:
 
 .. code-block:: python
 
-   configure_directory = "src"
+   configure_directory = 'src'
 
 ^^^^^^^^^^^^^^^^^^^^^^
 Building out of source
@@ -522,7 +491,7 @@ This can be done using the ``build_directory`` variable:
 
 .. code-block:: python
 
-   build_directory = "spack-build"
+   build_directory = 'spack-build'
 
 By default, Spack will build the package in the same directory that
 contains the ``configure`` script
@@ -545,8 +514,8 @@ library or build the documentation, you can add these like so:
 
 .. code-block:: python
 
-   build_targets = ["all", "docs"]
+   build_targets = ['all', 'docs']
-   install_targets = ["install", "docs"]
+   install_targets = ['install', 'docs']
 
 ^^^^^^^
 Testing

lib/spack/docs/build_systems/bundlepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -8,32 +9,9 @@
 Bundle
 ------
 
-``BundlePackage`` represents a set of packages that are expected to work
+``BundlePackage`` represents a set of packages that are expected to work well
-well together, such as a collection of commonly used software libraries.
+together, such as a collection of commonly used software libraries.  The
-The associated software is specified as dependencies.
+associated software is specified as bundle dependencies.
-
-If it makes sense, variants, conflicts, and requirements can be added to
-the package. :ref:`Variants <variants>` ensure that common build options
-are consistent across the packages supporting them.  :ref:`Conflicts
-and requirements <packaging_conflicts>` prevent attempts to build with known
-bugs or limitations.
-
-For example, if ``MyBundlePackage`` is known to only build on ``linux``,
-it could use the ``require`` directive as follows:
-
-.. code-block:: python
-
-    require("platform=linux", msg="MyBundlePackage only builds on linux")
-
-Spack has a number of built-in bundle packages, such as:
-
-* `AmdAocl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/amd-aocl/package.py>`_
-* `EcpProxyApps <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/ecp-proxy-apps/package.py>`_
-* `Libc <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/libc/package.py>`_
-* `Xsdk <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/xsdk/package.py>`_
-
-where ``Xsdk`` also inherits from ``CudaPackage`` and ``RocmPackage`` and
-``Libc`` is a virtual bundle package for the C standard library.
 
 
 ^^^^^^^^

lib/spack/docs/build_systems/cachedcmakepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -86,7 +87,7 @@ A typical usage of these methods may look something like this:
 
 .. code-block:: python
 
-   def initconfig_mpi_entries(self):
+   def initconfig_mpi_entries(self)
        # Get existing MPI configurations
        entries = super(self, Foo).initconfig_mpi_entries()
 
@@ -94,25 +95,25 @@ A typical usage of these methods may look something like this:
        # This spec has an MPI variant, and we need to enable MPI when it is on.
        # This hypothetical package controls MPI with the ``FOO_MPI`` option to
        # cmake.
-       if self.spec.satisfies("+mpi"):
+       if '+mpi' in self.spec:
-           entries.append(cmake_cache_option("FOO_MPI", True, "enable mpi"))
+           entries.append(cmake_cache_option('FOO_MPI', True, "enable mpi"))
        else:
-           entries.append(cmake_cache_option("FOO_MPI", False, "disable mpi"))
+           entries.append(cmake_cache_option('FOO_MPI', False, "disable mpi"))
 
    def initconfig_package_entries(self):
        # Package specific options
        entries = []
 
-       entries.append("#Entries for build options")
+       entries.append('#Entries for build options')
 
-       bar_on = self.spec.satisfies("+bar")
+       bar_on = '+bar' in self.spec
-       entries.append(cmake_cache_option("FOO_BAR", bar_on, "toggle bar"))
+       entries.append(cmake_cache_option('FOO_BAR', bar_on, 'toggle bar'))
 
-       entries.append("#Entries for dependencies")
+       entries.append('#Entries for dependencies')
 
-       if self.spec["blas"].name == "baz":  # baz is our blas provider
+       if self.spec['blas'].name == 'baz':  # baz is our blas provider
-           entries.append(cmake_cache_string("FOO_BLAS", "baz", "Use baz"))
+       entries.append(cmake_cache_string('FOO_BLAS', 'baz', 'Use baz'))
-           entries.append(cmake_cache_path("BAZ_PREFIX", self.spec["baz"].prefix))
+       entries.append(cmake_cache_path('BAZ_PREFIX', self.spec['baz'].prefix))
 
 ^^^^^^^^^^^^^^^^^^^^^^
 External documentation

lib/spack/docs/build_systems/cmakepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -81,7 +82,7 @@ class already contains:
 
 .. code-block:: python
 
-   depends_on("cmake", type="build")
+   depends_on('cmake', type='build')
 
 
 If you need to specify a particular version requirement, you can
@@ -89,7 +90,7 @@ override this in your package:
 
 .. code-block:: python
 
-   depends_on("cmake@2.8.12:", type="build")
+   depends_on('cmake@2.8.12:', type='build')
 
 
 ^^^^^^^^^^^^^^^^^^^
@@ -136,10 +137,10 @@ and without the :meth:`~spack.build_systems.cmake.CMakeBuilder.define` and
 
    def cmake_args(self):
        args = [
-           "-DWHATEVER:STRING=somevalue",
+           '-DWHATEVER:STRING=somevalue',
-           self.define("ENABLE_BROKEN_FEATURE", False),
+           self.define('ENABLE_BROKEN_FEATURE', False),
-           self.define_from_variant("DETECT_HDF5", "hdf5"),
+           self.define_from_variant('DETECT_HDF5', 'hdf5'),
-           self.define_from_variant("THREADS"), # True if +threads
+           self.define_from_variant('THREADS'), # True if +threads
        ]
 
        return args
@@ -150,10 +151,10 @@ and CMake simply ignores the empty command line argument. For example the follow
 
 .. code-block:: python
 
-   variant("example", default=True, when="@2.0:")
+   variant('example', default=True, when='@2.0:')
 
    def cmake_args(self):
-      return [self.define_from_variant("EXAMPLE", "example")]
+      return [self.define_from_variant('EXAMPLE', 'example')]
 
 will generate ``'cmake' '-DEXAMPLE=ON' ...`` when `@2.0: +example` is met, but will
 result in ``'cmake' '' ...`` when the spec version is below ``2.0``.
@@ -192,9 +193,9 @@ a variant to control this:
 
 .. code-block:: python
 
-   variant("build_type", default="RelWithDebInfo",
+   variant('build_type', default='RelWithDebInfo',
-           description="CMake build type",
+           description='CMake build type',
-           values=("Debug", "Release", "RelWithDebInfo", "MinSizeRel"))
+           values=('Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel'))
 
 However, not every CMake package accepts all four of these options.
 Grep the ``CMakeLists.txt`` file to see if the default values are
@@ -204,9 +205,9 @@ package overrides the default variant with:
 
 .. code-block:: python
 
-   variant("build_type", default="DebugRelease",
+   variant('build_type', default='DebugRelease',
-           description="The build type to build",
+           description='The build type to build',
-           values=("Debug", "Release", "DebugRelease"))
+           values=('Debug', 'Release', 'DebugRelease'))
 
 For more information on ``CMAKE_BUILD_TYPE``, see:
 https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
@@ -249,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
@@ -257,7 +258,7 @@ Ninja generator, make sure to add:
 
 .. code-block:: python
 
-   depends_on("ninja", type="build")
+   depends_on('ninja', type='build')
 
 to the package as well. Aside from that, you shouldn't need to do
 anything else. Spack will automatically detect that you are using
@@ -287,7 +288,7 @@ like so:
 
 .. code-block:: python
 
-   root_cmakelists_dir = "src"
+   root_cmakelists_dir = 'src'
 
 
 Note that this path is relative to the root of the extracted tarball,
@@ -303,7 +304,7 @@ different sub-directory, simply override ``build_directory`` like so:
 
 .. code-block:: python
 
-   build_directory = "my-build"
+   build_directory = 'my-build'
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Build and install targets
@@ -323,8 +324,8 @@ library or build the documentation, you can add these like so:
 
 .. code-block:: python
 
-   build_targets = ["all", "docs"]
+   build_targets = ['all', 'docs']
-   install_targets = ["install", "docs"]
+   install_targets = ['install', 'docs']
 
 ^^^^^^^
 Testing

lib/spack/docs/build_systems/cudapackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -53,8 +54,8 @@ to terminate such build attempts with a suitable message:
 
 .. code-block:: python
 
-    conflicts("cuda_arch=none", when="+cuda",
+    conflicts('cuda_arch=none', when='+cuda',
-              msg="CUDA architecture is required")
+              msg='CUDA architecture is required')
 
 Similarly, if your software does not support all versions of the property,
 you could add ``conflicts`` to your package for those versions.  For example,
@@ -65,13 +66,13 @@ custom message should a user attempt such a build:
 .. code-block:: python
 
     unsupported_cuda_archs = [
-        "10", "11", "12", "13",
+        '10', '11', '12', '13',
-        "20", "21",
+        '20', '21',
-        "30", "32", "35", "37"
+        '30', '32', '35', '37'
     ]
     for value in unsupported_cuda_archs:
-        conflicts(f"cuda_arch={value}", when="+cuda",
+        conflicts('cuda_arch={0}'.format(value), when='+cuda',
-                  msg=f"CUDA architecture {value} is not supported")
+                  msg='CUDA architecture {0} is not supported'.format(value))
 
 ^^^^^^^
 Methods
@@ -106,16 +107,16 @@ class of your package.  For example, you can add it to your
             spec = self.spec
             args = []
             ...
-            if spec.satisfies("+cuda"):
+            if '+cuda' in spec:
                 # Set up the cuda macros needed by the build
-                args.append("-DWITH_CUDA=ON")
+                args.append('-DWITH_CUDA=ON')
-                cuda_arch_list = spec.variants["cuda_arch"].value
+                cuda_arch_list = spec.variants['cuda_arch'].value
                 cuda_arch = cuda_arch_list[0]
-                if cuda_arch != "none":
+                if cuda_arch != 'none':
-                    args.append(f"-DCUDA_FLAGS=-arch=sm_{cuda_arch}")
+                    args.append('-DCUDA_FLAGS=-arch=sm_{0}'.format(cuda_arch))
             else:
                 # Ensure build with cuda is disabled
-                args.append("-DWITH_CUDA=OFF")
+                args.append('-DWITH_CUDA=OFF')
             ...
             return args
 
@@ -124,7 +125,7 @@ You will need to customize options as needed for your build.
 
 This example also illustrates how to check for the ``cuda`` variant using
 ``self.spec`` and how to retrieve the ``cuda_arch`` variant's value, which
-is a list, using ``self.spec.variants["cuda_arch"].value``.
+is a list, using ``self.spec.variants['cuda_arch'].value``.
 
 With over 70 packages using ``CudaPackage`` as of January 2021 there are
 lots of examples to choose from to get more ideas for using this package.

lib/spack/docs/build_systems/custompackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -56,13 +57,13 @@ If you look at the ``perl`` package, you'll see:
 
 .. code-block:: python
 
-   phases = ("configure", "build", "install")
+   phases = ['configure', 'build', 'install']
 
 Similarly, ``cmake`` defines:
 
 .. code-block:: python
 
-   phases = ("bootstrap", "build", "install")
+   phases = ['bootstrap', 'build', 'install']
 
 If we look at the ``cmake`` example, this tells Spack's ``PackageBase``
 class to run the ``bootstrap``, ``build``, and ``install`` functions
@@ -77,7 +78,7 @@ If we look at ``perl``, we see that it defines a ``configure`` method:
 .. code-block:: python
 
    def configure(self, spec, prefix):
-       configure = Executable("./Configure")
+       configure = Executable('./Configure')
        configure(*self.configure_args())
 
 There is also a corresponding ``configure_args`` function that handles
@@ -91,7 +92,7 @@ phases are pretty simple:
        make()
 
    def install(self, spec, prefix):
-       make("install")
+       make('install')
 
 The ``cmake`` package looks very similar, but with a ``bootstrap``
 function instead of ``configure``:
@@ -99,14 +100,14 @@ function instead of ``configure``:
 .. code-block:: python
 
    def bootstrap(self, spec, prefix):
-       bootstrap = Executable("./bootstrap")
+       bootstrap = Executable('./bootstrap')
        bootstrap(*self.bootstrap_args())
 
    def build(self, spec, prefix):
        make()
 
    def install(self, spec, prefix):
-       make("install")
+       make('install')
 
 Again, there is a ``boostrap_args`` function that determines the
 correct bootstrap flags to use.
@@ -127,21 +128,16 @@ before or after a particular phase. For example, in ``perl``, we see:
 
 .. code-block:: python
 
-   @run_after("install")
+   @run_after('install')
    def install_cpanm(self):
-        spec = self.spec
+       spec = self.spec
-        maker = make
+
-        cpan_dir = join_path("cpanm", "cpanm")
+       if '+cpanm' in spec:
-        if sys.platform == "win32":
+           with working_dir(join_path('cpanm', 'cpanm')):
-            maker = nmake
+               perl = spec['perl'].command
-            cpan_dir = join_path(self.stage.source_path, cpan_dir)
+               perl('Makefile.PL')
-            cpan_dir = windows_sfn(cpan_dir)
+               make()
-        if "+cpanm" in spec:
+               make('install')
-            with working_dir(cpan_dir):
-                perl = spec["perl"].command
-                perl("Makefile.PL")
-                maker()
-                maker("install")
 
 This extra step automatically installs ``cpanm`` in addition to the
 base Perl installation.
@@ -178,16 +174,10 @@ In the ``perl`` package, we can see:
 
 .. code-block:: python
 
-   @run_after("build")
+   @run_after('build')
    @on_package_attributes(run_tests=True)
-   def build_test(self):
+   def test(self):
-        if sys.platform == "win32":
+       make('test')
-            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")
 
 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
@@ -199,7 +189,7 @@ custom build systems, it can be added to existing build systems as well.
 
    .. code-block:: python
 
-      @run_after("install")
+      @run_after('install')
       @on_package_attributes(run_tests=True)
 
    works as expected. However, if you reverse the ordering:
@@ -207,7 +197,7 @@ custom build systems, it can be added to existing build systems as well.
    .. code-block:: python
 
       @on_package_attributes(run_tests=True)
-      @run_after("install")
+      @run_after('install')
 
    the tests will always be run regardless of whether or not
    ``--test=root`` is requested. See https://github.com/spack/spack/issues/3833

lib/spack/docs/build_systems/inteloneapipackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -24,8 +25,8 @@ 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. See the :ref:`package-list` for the full list of available
-list of available oneAPI packages, or use::
+oneAPI packages or use::
 
   spack list -d oneAPI
 
@@ -33,6 +34,9 @@ For more information on a specific package, do::
 
   spack info --all <package-name>
 
+Intel no longer releases new versions of Parallel Studio, which can be
+used in Spack via the :ref:`intelpackage`. All of its components can
+now be found in oneAPI.
 
 Examples
 ========
@@ -47,51 +51,31 @@ Install the oneAPI compilers::
 
   spack install intel-oneapi-compilers
 
+Add the compilers to your ``compilers.yaml`` so spack can use them::
 
-To build the ``patchelf`` Spack package with ``icx``, do::
+  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin/intel64
+  spack compiler add `spack location -i intel-oneapi-compilers`/compiler/latest/linux/bin
+
+Verify that the compilers are available::
+
+  spack compiler list
+
+The ``intel-oneapi-compilers`` package includes 2 families of
+compilers:
+
+* ``intel``: ``icc``, ``icpc``, ``ifort``. Intel's *classic*
+  compilers.
+* ``oneapi``: ``icx``, ``icpx``, ``ifx``. Intel's new generation of
+  compilers based on LLVM.
+
+To build the ``patchelf`` Spack package with ``icc``, do::
+
+  spack install patchelf%intel
+
+To build with with ``icx``, do ::
 
   spack install patchelf%oneapi
 
-
-Using oneAPI Spack environment
--------------------------------
-
-In this example, we build lammps with ``icx`` using Spack environment for oneAPI packages created by Intel. The
-compilers are installed with Spack like in example above.
-
-Install the oneAPI compilers::
-
-  spack install intel-oneapi-compilers
-
-Clone `spack-configs <https://github.com/spack/spack-configs>`_ repo and activate Intel oneAPI CPU environment::
-
-  git clone https://github.com/spack/spack-configs
-  spack env activate spack-configs/INTEL/CPU
-  spack concretize -f
-
-`Intel oneAPI CPU environment <https://github.com/spack/spack-configs/blob/main/INTEL/CPU/spack.yaml>`_  contains applications tested and validated by Intel, this list is constantly extended. And currently it supports:
-
-- `Devito <https://www.devitoproject.org/>`_
-- `GROMACS <https://www.gromacs.org/>`_
-- `HPCG <https://www.hpcg-benchmark.org/>`_
-- `HPL <https://netlib.org/benchmark/hpl/>`_
-- `LAMMPS <https://www.lammps.org/#gsc.tab=0>`_
-- `OpenFOAM <https://www.openfoam.com/>`_
-- `Quantum Espresso <https://www.quantum-espresso.org/>`_
-- `STREAM <https://www.cs.virginia.edu/stream/>`_
-- `WRF <https://github.com/wrf-model/WRF>`_
-
-To build lammps with oneAPI compiler from this environment just run::
-
-  spack install lammps
-
-Compiled binaries can be find using::
-
-  spack cd -i lammps
-
-You can do the same for all other applications from this environment.
-
-
 Using oneAPI MPI to Satisfy a Virtual Dependence
 ------------------------------------------------------
 
@@ -111,23 +95,18 @@ Compilers
 ---------
 
 To use the compilers, add some information about the installation to
-``packages.yaml``. For most users, it is sufficient to do::
+``compilers.yaml``. For most users, it is sufficient to do::
 
-  spack compiler add /opt/intel/oneapi/compiler/latest/bin
+  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin/intel64
+  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin
 
 Adapt the paths above if you did not install the tools in the default
 location. After adding the compilers, using them is the same
 as if you had installed the ``intel-oneapi-compilers`` package.
 Another option is to manually add the configuration to
-``packages.yaml`` as described in :ref:`Compiler configuration
+``compilers.yaml`` as described in :ref:`Compiler configuration
 <compiler-config>`.
 
-Before 2024, the directory structure was different::
-  
-  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin/intel64
-  spack compiler add /opt/intel/oneapi/compiler/latest/linux/bin
-
-
 Libraries
 ---------
 
@@ -162,5 +141,15 @@ You can also use Spack-installed libraries. For example::
 Will update your environment CPATH, LIBRARY_PATH, and other
 environment variables for building an application with oneMKL.
 
+More information
+================
+
+This section describes basic use of oneAPI, especially if it has
+changed compared to Parallel Studio. See :ref:`intelpackage` for more
+information on :ref:`intel-virtual-packages`,
+:ref:`intel-unrelated-packages`,
+:ref:`intel-integrating-external-libraries`, and
+:ref:`using-mkl-tips`.
+
 
 .. _`Intel installers`: https://software.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-linux/top.html

lib/spack/docs/build_systems/luapackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -87,7 +88,7 @@ override the ``luarocks_args`` method like so:
 .. code-block:: python
 
     def luarocks_args(self):
-        return ["flag1", "flag2"]
+        return ['flag1', 'flag2']
 
 One common use of this is to override warnings or flags for newer compilers, as in:
 

lib/spack/docs/build_systems/makefilepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -58,7 +59,7 @@ using GNU Make, you should add a dependency on ``gmake``:
 
 .. code-block:: python
 
-   depends_on("gmake", type="build")
+   depends_on('gmake', type='build')
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -87,13 +88,13 @@ command-line. However, Makefiles that use ``?=`` for assignment honor
 environment variables. Since Spack already sets ``CC``, ``CXX``, ``F77``,
 and ``FC``, you won't need to worry about setting these variables. If
 there are any other variables you need to set, you can do this in the
-``setup_build_environment`` method:
+``edit`` method:
 
 .. code-block:: python
 
-   def setup_build_environment(self, env: EnvironmentModifications) -> None:
+   def edit(self, spec, prefix):
-       env.set("PREFIX", prefix)
+       env['PREFIX'] = prefix
-       env.set("BLASLIB", spec["blas"].libs.ld_flags)
+       env['BLASLIB'] = spec['blas'].libs.ld_flags
 
 
 `cbench <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cbench/package.py>`_
@@ -112,7 +113,7 @@ you can do this like so:
 
 .. code-block:: python
 
-   build_targets = ["CC=cc"]
+   build_targets = ['CC=cc']
 
 
 If you do need access to the spec, you can create a property like so:
@@ -124,8 +125,8 @@ If you do need access to the spec, you can create a property like so:
        spec = self.spec
 
        return [
-           "CC=cc",
+           'CC=cc',
-           f"BLASLIB={spec['blas'].libs.ld_flags}",
+           'BLASLIB={0}'.format(spec['blas'].libs.ld_flags),
        ]
 
 
@@ -139,17 +140,17 @@ Edit Makefile
 Some Makefiles are just plain stubborn and will ignore command-line
 variables. The only way to ensure that these packages build correctly
 is to directly edit the Makefile. Spack provides a ``FileFilter`` class
-and a ``filter`` method to help with this. For example:
+and a ``filter_file`` method to help with this. For example:
 
 .. code-block:: python
 
    def edit(self, spec, prefix):
-       makefile = FileFilter("Makefile")
+       makefile = FileFilter('Makefile')
 
-       makefile.filter(r"^\s*CC\s*=.*",  f"CC = {spack_cc}")
+       makefile.filter(r'^\s*CC\s*=.*',  'CC = '  + spack_cc)
-       makefile.filter(r"^\s*CXX\s*=.*", f"CXX = {spack_cxx}")
+       makefile.filter(r'^\s*CXX\s*=.*', 'CXX = ' + spack_cxx)
-       makefile.filter(r"^\s*F77\s*=.*", f"F77 = {spack_f77}")
+       makefile.filter(r'^\s*F77\s*=.*', 'F77 = ' + spack_f77)
-       makefile.filter(r"^\s*FC\s*=.*",  f"FC = {spack_fc}")
+       makefile.filter(r'^\s*FC\s*=.*',  'FC = '  + spack_fc)
 
 
 `stream <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/stream/package.py>`_
@@ -180,16 +181,16 @@ well for storing variables:
 
    def edit(self, spec, prefix):
        config = {
-           "CC": "cc",
+           'CC': 'cc',
-           "MAKE": "make",
+           'MAKE': 'make',
        }
 
-       if spec.satisfies("+blas"):
+       if '+blas' in spec:
-           config["BLAS_LIBS"] = spec["blas"].libs.joined()
+           config['BLAS_LIBS'] = spec['blas'].libs.joined()
 
-       with open("make.inc", "w") as inc:
+       with open('make.inc', 'w') as inc:
            for key in config:
-               inc.write(f"{key} = {config[key]}\n")
+               inc.write('{0} = {1}\n'.format(key, config[key]))
 
 
 `elk <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/elk/package.py>`_
@@ -203,14 +204,14 @@ them in a list:
 
    def edit(self, spec, prefix):
        config = [
-           f"INSTALL_DIR = {prefix}",
+           'INSTALL_DIR = {0}'.format(prefix),
-           "INCLUDE_DIR = $(INSTALL_DIR)/include",
+           'INCLUDE_DIR = $(INSTALL_DIR)/include',
-           "LIBRARY_DIR = $(INSTALL_DIR)/lib",
+           'LIBRARY_DIR = $(INSTALL_DIR)/lib',
        ]
 
-       with open("make.inc", "w") as inc:
+       with open('make.inc', 'w') as inc:
            for var in config:
-               inc.write(f"{var}\n")
+               inc.write('{0}\n'.format(var))
 
 
 `hpl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/hpl/package.py>`_
@@ -283,7 +284,7 @@ can tell Spack where to locate it like so:
 
 .. code-block:: python
 
-   build_directory = "src"
+   build_directory = 'src'
 
 
 ^^^^^^^^^^^^^^^^^^^
@@ -298,8 +299,8 @@ install the package:
 
    def install(self, spec, prefix):
        mkdir(prefix.bin)
-       install("foo", prefix.bin)
+       install('foo', prefix.bin)
-       install_tree("lib", prefix.lib)
+       install_tree('lib', prefix.lib)
 
 
 ^^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/mavenpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -47,8 +48,8 @@ class automatically adds the following dependencies:
 
 .. code-block:: python
 
-   depends_on("java", type=("build", "run"))
+   depends_on('java', type=('build', 'run'))
-   depends_on("maven", type="build")
+   depends_on('maven', type='build')
 
 
 In the ``pom.xml`` file, you may see sections like:
@@ -71,8 +72,8 @@ should add:
 
 .. code-block:: python
 
-   depends_on("java@7:", type="build")
+   depends_on('java@7:', type='build')
-   depends_on("maven@3.5.4:", type="build")
+   depends_on('maven@3.5.4:', type='build')
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -87,9 +88,9 @@ the build phase. For example:
 
    def build_args(self):
        return [
-           "-Pdist,native",
+           '-Pdist,native',
-           "-Dtar",
+           '-Dtar',
-           "-Dmaven.javadoc.skip=true"
+           '-Dmaven.javadoc.skip=true'
        ]
 
 

lib/spack/docs/build_systems/mesonpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -85,8 +86,8 @@ the ``MesonPackage`` base class already contains:
 
 .. code-block:: python
 
-   depends_on("meson", type="build")
+   depends_on('meson', type='build')
-   depends_on("ninja", type="build")
+   depends_on('ninja', type='build')
 
 
 If you need to specify a particular version requirement, you can
@@ -94,8 +95,8 @@ override this in your package:
 
 .. code-block:: python
 
-   depends_on("meson@0.43.0:", type="build")
+   depends_on('meson@0.43.0:', type='build')
-   depends_on("ninja", type="build")
+   depends_on('ninja', type='build')
 
 
 ^^^^^^^^^^^^^^^^^^^
@@ -120,7 +121,7 @@ override the ``meson_args`` method like so:
 .. code-block:: python
 
    def meson_args(self):
-       return ["--warnlevel=3"]
+       return ['--warnlevel=3']
 
 
 This method can be used to pass flags as well as variables.

lib/spack/docs/build_systems/octavepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

lib/spack/docs/build_systems/perlpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -117,7 +118,7 @@ so ``PerlPackage`` contains:
 
 .. code-block:: python
 
-   extends("perl")
+   extends('perl')
 
 
 If your package requires a specific version of Perl, you should
@@ -131,14 +132,14 @@ properly. If your package uses ``Makefile.PL`` to build, add:
 
 .. code-block:: python
 
-   depends_on("perl-extutils-makemaker", type="build")
+   depends_on('perl-extutils-makemaker', type='build')
 
 
 If your package uses ``Build.PL`` to build, add:
 
 .. code-block:: python
 
-   depends_on("perl-module-build", type="build")
+   depends_on('perl-module-build', type='build')
 
 
 ^^^^^^^^^^^^^^^^^
@@ -164,80 +165,14 @@ arguments to ``Makefile.PL`` or ``Build.PL`` by overriding
 .. code-block:: python
 
    def configure_args(self):
-       expat = self.spec["expat"].prefix
+       expat = self.spec['expat'].prefix
 
        return [
-           "EXPATLIBPATH={0}".format(expat.lib),
+           'EXPATLIBPATH={0}'.format(expat.lib),
-           "EXPATINCPATH={0}".format(expat.include),
+           'EXPATINCPATH={0}'.format(expat.include),
        ]
 
 
-^^^^^^^
-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

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -151,16 +152,16 @@ set. Once set, ``pypi`` will be used to define the ``homepage``,
 
 .. code-block:: python
 
-   homepage = "https://pypi.org/project/setuptools/"
+   homepage = 'https://pypi.org/project/setuptools/'
-   url      = "https://pypi.org/packages/source/s/setuptools/setuptools-49.2.0.zip"
+   url      = 'https://pypi.org/packages/source/s/setuptools/setuptools-49.2.0.zip'
-   list_url = "https://pypi.org/simple/setuptools/"
+   list_url = 'https://pypi.org/simple/setuptools/'
 
 
 is equivalent to:
 
 .. code-block:: python
 
-   pypi = "setuptools/setuptools-49.2.0.zip"
+   pypi = 'setuptools/setuptools-49.2.0.zip'
 
 
 If a package has a different homepage listed on PyPI, you can
@@ -207,7 +208,7 @@ dependencies to your package:
 
 .. code-block:: python
 
-   depends_on("py-setuptools@42:", type="build")
+   depends_on('py-setuptools@42:', type='build')
 
 
 Note that ``py-wheel`` is already listed as a build dependency in the
@@ -231,7 +232,7 @@ Look for dependencies under the following keys:
 * ``dependencies`` under ``[project]``
 
   These packages are required for building and installation. You can
-  add them with ``type=("build", "run")``.
+  add them with ``type=('build', 'run')``.
 
 * ``[project.optional-dependencies]``
 
@@ -278,12 +279,12 @@ distutils library, and has almost the exact same API. In addition to
 * ``setup_requires``
 
   These packages are usually only needed at build-time, so you can
-  add them with ``type="build"``.
+  add them with ``type='build'``.
 
 * ``install_requires``
 
   These packages are required for building and installation. You can
-  add them with ``type=("build", "run")``.
+  add them with ``type=('build', 'run')``.
 
 * ``extras_require``
 
@@ -295,7 +296,7 @@ distutils library, and has almost the exact same API. In addition to
 
   These are packages that are required to run the unit tests for the
   package. These dependencies can be specified using the
-  ``type="test"`` dependency type. However, the PyPI tarballs rarely
+  ``type='test'`` dependency type. However, the PyPI tarballs rarely
   contain unit tests, so there is usually no reason to add these.
 
 See https://setuptools.pypa.io/en/latest/userguide/dependency_management.html
@@ -320,7 +321,7 @@ older versions of flit may use the following keys:
 * ``requires`` under ``[tool.flit.metadata]``
 
   These packages are required for building and installation. You can
-  add them with ``type=("build", "run")``.
+  add them with ``type=('build', 'run')``.
 
 * ``[tool.flit.metadata.requires-extra]``
 
@@ -433,12 +434,12 @@ the BLAS/LAPACK library you want pkg-config to search for:
 
 .. code-block:: python
 
-   depends_on("py-pip@22.1:", type="build")
+   depends_on('py-pip@22.1:', type='build')
 
    def config_settings(self, spec, prefix):
        return {
-           "blas": spec["blas"].libs.names[0],
+           'blas': spec['blas'].libs.names[0],
-           "lapack": spec["lapack"].libs.names[0],
+           'lapack': spec['lapack'].libs.names[0],
        }
 
 
@@ -462,10 +463,10 @@ has an optional dependency on ``libyaml`` that can be enabled like so:
 
    def global_options(self, spec, prefix):
        options = []
-       if spec.satisfies("+libyaml"):
+       if '+libyaml' in spec:
-           options.append("--with-libyaml")
+           options.append('--with-libyaml')
        else:
-           options.append("--without-libyaml")
+           options.append('--without-libyaml')
        return options
 
 
@@ -491,10 +492,10 @@ allows you to specify the directories to search for ``libyaml``:
 
    def install_options(self, spec, prefix):
        options = []
-       if spec.satisfies("+libyaml"):
+       if '+libyaml' in spec:
            options.extend([
-               spec["libyaml"].libs.search_flags,
+               spec['libyaml'].libs.search_flags,
-               spec["libyaml"].headers.include_flags,
+               spec['libyaml'].headers.include_flags,
            ])
        return options
 
@@ -555,7 +556,7 @@ detected are wrong, you can provide the names yourself by overriding
 
 .. code-block:: python
 
-   import_modules = ["six"]
+   import_modules = ['six']
 
 
 Sometimes the list of module names to import depends on how the
@@ -570,9 +571,9 @@ This can be expressed like so:
 
    @property
    def import_modules(self):
-       modules = ["yaml"]
+       modules = ['yaml']
-       if self.spec.satisfies("+libyaml"):
+       if '+libyaml' in self.spec:
-           modules.append("yaml.cyaml")
+           modules.append('yaml.cyaml')
        return modules
 
 
@@ -585,14 +586,14 @@ Instead of defining the ``import_modules`` explicitly, only the subset
 of module names to be skipped can be defined by using ``skip_modules``.
 If a defined module has submodules, they are skipped as well, e.g.,
 in case the ``plotting`` modules should be excluded from the
-automatically detected ``import_modules`` ``["nilearn", "nilearn.surface",
+automatically detected ``import_modules`` ``['nilearn', 'nilearn.surface',
-"nilearn.plotting", "nilearn.plotting.data"]`` set:
+'nilearn.plotting', 'nilearn.plotting.data']`` set:
 
 .. code-block:: python
 
-        skip_modules = ["nilearn.plotting"]
+        skip_modules = ['nilearn.plotting']
 
-This will set ``import_modules`` to ``["nilearn", "nilearn.surface"]``
+This will set ``import_modules`` to ``['nilearn', 'nilearn.surface']``
 
 Import tests can be run during the installation using ``spack install
 --test=root`` or at any time after the installation using
@@ -611,11 +612,11 @@ after the ``install`` phase:
 
 .. code-block:: python
 
-   @run_after("install")
+   @run_after('install')
    @on_package_attributes(run_tests=True)
    def install_test(self):
-       with working_dir("spack-test", create=True):
+       with working_dir('spack-test', create=True):
-           python("-c", "import numpy; numpy.test('full', verbose=2)")
+           python('-c', 'import numpy; numpy.test("full", verbose=2)')
 
 
 when testing is enabled during the installation (i.e., ``spack install
@@ -637,7 +638,7 @@ provides Python bindings in a ``python`` directory, you can use:
 
 .. code-block:: python
 
-   build_directory = "python"
+   build_directory = 'python'
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -717,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
+When deciding between ``extends`` and ``depends_on``, the best rule of
-``python-venv``. This improves isolation from the system, whether
+thumb is to check the installation prefix. If Python libraries are
-it's during the build or at runtime: user and system site packages
+installed to ``<prefix>/lib/pythonX.Y/site-packages``, then you
-cannot accidentally be used by any package that ``extends("python")``.
+should use ``extends``. If Python libraries are installed elsewhere
-
+or the only files that get installed reside in ``<prefix>/bin``, then
-As a rule of thumb: if a package does not install any Python modules
+don't use ``extends``.
-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")``.
 
 ^^^^^^^^^^^^^^^^^^^^^
 Alternatives to Spack

lib/spack/docs/build_systems/qmakepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -24,14 +25,6 @@ QMake does not appear to have a standardized way of specifying
 the installation directory, so you may have to set environment
 variables or edit ``*.pro`` files to get things working properly.
 
-QMake packages will depend on the virtual ``qmake`` package which
-is provided by multiple versions of Qt: ``qt`` provides Qt up to
-Qt5, and ``qt-base`` provides Qt from version Qt6 onwards. This
-split was motivated by the desire to split the single Qt package
-into its components to allow for more fine-grained installation.
-To depend on a specific version, refer to the documentation on
-:ref:`virtual-dependencies`.
-
 ^^^^^^
 Phases
 ^^^^^^
@@ -90,7 +83,7 @@ base class already contains:
 
 .. code-block:: python
 
-   depends_on("qt", type="build")
+   depends_on('qt', type='build')
 
 
 If you want to specify a particular version requirement, or need to
@@ -98,7 +91,7 @@ link to the ``qt`` libraries, you can override this in your package:
 
 .. code-block:: python
 
-   depends_on("qt@5.6.0:")
+   depends_on('qt@5.6.0:')
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 Passing arguments to qmake
@@ -110,7 +103,7 @@ override the ``qmake_args`` method like so:
 .. code-block:: python
 
    def qmake_args(self):
-       return ["-recursive"]
+       return ['-recursive']
 
 
 This method can be used to pass flags as well as variables.
@@ -125,7 +118,7 @@ sub-directory by adding the following to the package:
 
 .. code-block:: python
 
-   build_directory = "src"
+   build_directory = 'src'
 
 
 ^^^^^^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/racketpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

lib/spack/docs/build_systems/rocmpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -12,7 +13,8 @@ The ``ROCmPackage`` is not a build system but a helper package. Like ``CudaPacka
 it provides standard variants, dependencies, and conflicts to facilitate building
 packages using GPUs though for AMD in this case.
 
-You can find the source for this package (and suggestions for setting up your ``packages.yaml`` file) at
+You can find the source for this package (and suggestions for setting up your
+``compilers.yaml`` and ``packages.yaml`` files) at
 `<https://github.com/spack/spack/blob/develop/lib/spack/spack/build_systems/rocm.py>`__.
 
 ^^^^^^^^
@@ -79,27 +81,28 @@ class of your package.  For example, you can add it to your
     class MyRocmPackage(CMakePackage, ROCmPackage):
         ...
         # Ensure +rocm and amdgpu_targets are passed to dependencies
-        depends_on("mydeppackage", when="+rocm")
+        depends_on('mydeppackage', when='+rocm')
         for val in ROCmPackage.amdgpu_targets:
-            depends_on(f"mydeppackage amdgpu_target={val}",
+            depends_on('mydeppackage amdgpu_target={0}'.format(val),
-                       when=f"amdgpu_target={val}")
+                       when='amdgpu_target={0}'.format(val))
         ...
 
         def cmake_args(self):
             spec = self.spec
             args = []
             ...
-            if spec.satisfies("+rocm"):
+            if '+rocm' in spec:
                 # Set up the hip macros needed by the build
                 args.extend([
-                    "-DENABLE_HIP=ON",
+                    '-DENABLE_HIP=ON',
-                    f"-DHIP_ROOT_DIR={spec['hip'].prefix}"])
+                    '-DHIP_ROOT_DIR={0}'.format(spec['hip'].prefix)])
-                rocm_archs = spec.variants["amdgpu_target"].value
+                rocm_archs = spec.variants['amdgpu_target'].value
-                if "none" not in rocm_archs:
+                if 'none' not in rocm_archs:
-                    args.append(f"-DHIP_HIPCC_FLAGS=--amdgpu-target={','.join(rocm_archs}")
+                    args.append('-DHIP_HIPCC_FLAGS=--amdgpu-target={0}'
+                                .format(",".join(rocm_archs)))
             else:
                 # Ensure build with hip is disabled
-                args.append("-DENABLE_HIP=OFF")
+                args.append('-DENABLE_HIP=OFF')
             ...
             return args
         ...
@@ -111,7 +114,7 @@ build.
 
 This example also illustrates how to check for the ``rocm`` variant using
 ``self.spec`` and how to retrieve the ``amdgpu_target`` variant's value
-using ``self.spec.variants["amdgpu_target"].value``.
+using ``self.spec.variants['amdgpu_target'].value``.
 
 All five packages using ``ROCmPackage`` as of January 2021 also use the
 :ref:`CudaPackage <cudapackage>`. So it is worth looking at those packages

lib/spack/docs/build_systems/rpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -162,28 +163,28 @@ attributes that can be used to set ``homepage``, ``url``, ``list_url``, and
 
 .. code-block:: python
 
-   cran = "caret"
+   cran = 'caret'
 
 is equivalent to:
 
 .. code-block:: python
 
-   homepage = "https://cloud.r-project.org/package=caret"
+   homepage = 'https://cloud.r-project.org/package=caret'
-   url      = "https://cloud.r-project.org/src/contrib/caret_6.0-86.tar.gz"
+   url      = 'https://cloud.r-project.org/src/contrib/caret_6.0-86.tar.gz'
-   list_url = "https://cloud.r-project.org/src/contrib/Archive/caret"
+   list_url = 'https://cloud.r-project.org/src/contrib/Archive/caret'
 
 Likewise, the following ``bioc`` attribute:
 
 .. code-block:: python
 
-   bioc = "BiocVersion"
+   bioc = 'BiocVersion'
 
 is equivalent to:
 
 .. code-block:: python
 
-   homepage = "https://bioconductor.org/packages/BiocVersion/"
+   homepage = 'https://bioconductor.org/packages/BiocVersion/'
-   git      = "https://git.bioconductor.org/packages/BiocVersion"
+   git      = 'https://git.bioconductor.org/packages/BiocVersion'
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -199,7 +200,7 @@ base class contains:
 
 .. code-block:: python
 
-   extends("r")
+   extends('r')
 
 
 Take a close look at the homepage for ``caret``. If you look at the
@@ -208,7 +209,7 @@ You should add this to your package like so:
 
 .. code-block:: python
 
-   depends_on("r@3.2.0:", type=("build", "run"))
+   depends_on('r@3.2.0:', type=('build', 'run'))
 
 
 ^^^^^^^^^^^^^^
@@ -226,7 +227,7 @@ and list all of their dependencies in the following sections:
 * LinkingTo
 
 As far as Spack is concerned, all 3 of these dependency types
-correspond to ``type=("build", "run")``, so you don't have to worry
+correspond to ``type=('build', 'run')``, so you don't have to worry
 about the details. If you are curious what they mean,
 https://github.com/spack/spack/issues/2951 has a pretty good summary:
 
@@ -329,7 +330,7 @@ the dependency:
 
 .. code-block:: python
 
-   depends_on("r-lattice@0.20:", type=("build", "run"))
+   depends_on('r-lattice@0.20:', type=('build', 'run'))
 
 
 ^^^^^^^^^^^^^^^^^^
@@ -360,20 +361,20 @@ like so:
 .. code-block:: python
 
    def configure_args(self):
-       mpi_name = self.spec["mpi"].name
+       mpi_name = self.spec['mpi'].name
 
        # The type of MPI. Supported values are:
        # OPENMPI, LAM, MPICH, MPICH2, or CRAY
-       if mpi_name == "openmpi":
+       if mpi_name == 'openmpi':
-           Rmpi_type = "OPENMPI"
+           Rmpi_type = 'OPENMPI'
-       elif mpi_name == "mpich":
+       elif mpi_name == 'mpich':
-           Rmpi_type = "MPICH2"
+           Rmpi_type = 'MPICH2'
        else:
-           raise InstallError("Unsupported MPI type")
+           raise InstallError('Unsupported MPI type')
 
        return [
-           "--with-Rmpi-type={0}".format(Rmpi_type),
+           '--with-Rmpi-type={0}'.format(Rmpi_type),
-           "--with-mpi={0}".format(spec["mpi"].prefix),
+           '--with-mpi={0}'.format(spec['mpi'].prefix),
        ]
 
 

lib/spack/docs/build_systems/rubypackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -83,8 +84,8 @@ The ``*.gemspec`` file may contain something like:
 
 .. code-block:: ruby
 
-   summary = "An implementation of the AsciiDoc text processor and publishing toolchain"
+   summary = 'An implementation of the AsciiDoc text processor and publishing toolchain'
-   description = "A fast, open source text processor and publishing toolchain for converting AsciiDoc content to HTML 5, DocBook 5, and other formats."
+   description = 'A fast, open source text processor and publishing toolchain for converting AsciiDoc content to HTML 5, DocBook 5, and other formats.'
 
 
 Either of these can be used for the description of the Spack package.
@@ -97,7 +98,7 @@ The ``*.gemspec`` file may contain something like:
 
 .. code-block:: ruby
 
-   homepage = "https://asciidoctor.org"
+   homepage = 'https://asciidoctor.org'
 
 
 This should be used as the official homepage of the Spack package.
@@ -111,21 +112,21 @@ the base class contains:
 
 .. code-block:: python
 
-   extends("ruby")
+   extends('ruby')
 
 
 The ``*.gemspec`` file may contain something like:
 
 .. code-block:: ruby
 
-   required_ruby_version = ">= 2.3.0"
+   required_ruby_version = '>= 2.3.0'
 
 
 This can be added to the Spack package using:
 
 .. code-block:: python
 
-   depends_on("ruby@2.3.0:", type=("build", "run"))
+   depends_on('ruby@2.3.0:', type=('build', 'run'))
 
 
 ^^^^^^^^^^^^^^^^^

lib/spack/docs/build_systems/sconspackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -48,15 +49,15 @@ 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")
+       scons('check')
 
 
 ^^^^^^^^^^^^^^^
@@ -87,7 +88,7 @@ base class already contains:
 
 .. code-block:: python
 
-   depends_on("scons", type="build")
+   depends_on('scons', type='build')
 
 
 If you want to specify a particular version requirement, you can override
@@ -95,7 +96,7 @@ this in your package:
 
 .. code-block:: python
 
-   depends_on("scons@2.3.0:", type="build")
+   depends_on('scons@2.3.0:', type='build')
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -237,14 +238,14 @@ the package build phase. This is done by overriding ``build_args`` like so:
 
    def build_args(self, spec, prefix):
        args = [
-         f"PREFIX={prefix}",
+         'PREFIX={0}'.format(prefix),
-         f"ZLIB={spec['zlib'].prefix}",
+         'ZLIB={0}'.format(spec['zlib'].prefix),
        ]
 
-       if spec.satisfies("+debug"):
+       if '+debug' in spec:
-           args.append("DEBUG=yes")
+           args.append('DEBUG=yes')
        else:
-           args.append("DEBUG=no")
+           args.append('DEBUG=no')
 
        return args
 
@@ -274,8 +275,8 @@ environment variables. For example, cantera has the following option:
    * env_vars: [ string ]
        Environment variables to propagate through to SCons. Either the
        string "all" or a comma separated list of variable names, e.g.
-       "LD_LIBRARY_PATH,HOME".
+       'LD_LIBRARY_PATH,HOME'.
-       - default: "LD_LIBRARY_PATH,PYTHONPATH"
+       - default: 'LD_LIBRARY_PATH,PYTHONPATH'
 
 
 In the case of cantera, using ``env_vars=all`` allows us to use

lib/spack/docs/build_systems/sippackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -31,7 +32,7 @@ By default, these phases run:
 
 .. code-block:: console
 
-   $ sip-build --verbose --target-dir ...
+   $ python configure.py --bindir ... --destdir ...
    $ make
    $ make install
 
@@ -40,30 +41,30 @@ By default, these phases run:
 Important files
 ^^^^^^^^^^^^^^^
 
-Each SIP package comes with a custom configuration file written in Python.
+Each SIP package comes with a custom ``configure.py`` build script,
-For newer packages, this is called ``project.py``, while in older packages,
+written in Python. This script contains instructions to build the project.
-it may be called ``configure.py``. This script contains instructions to build
-the project.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 Build system dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``SIPPackage`` requires several dependencies. Python and SIP are needed at build-time
+``SIPPackage`` requires several dependencies. Python is needed to run
-to run the aforementioned configure script. Python is also needed at run-time to
+the ``configure.py`` build script, and to run the resulting Python
-actually use the installed Python library. And as we are building Python bindings
+libraries. Qt is needed to provide the ``qmake`` command. SIP is also
-for C/C++ libraries, Python is also needed as a link dependency. All of these
+needed to build the package. All of these dependencies are automatically
-dependencies are automatically added via the base class.
+added via the base class
 
 .. code-block:: python
 
-   extends("python", type=("build", "link", "run"))
+   extends('python')
-   depends_on("py-sip", type="build")
 
+   depends_on('qt', type='build')
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+   depends_on('py-sip', type='build')
-Passing arguments to ``sip-build``
+
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Passing arguments to ``configure.py``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Each phase comes with a ``<phase_args>`` function that can be used to pass
 arguments to that particular phase. For example, if you need to pass
@@ -71,11 +72,11 @@ arguments to the configure phase, you can use:
 
 .. code-block:: python
 
-   def configure_args(self):
+   def configure_args(self, spec, prefix):
-       return ["--no-python-dbus"]
+       return ['--no-python-dbus']
 
 
-A list of valid options can be found by running ``sip-build --help``.
+A list of valid options can be found by running ``python configure.py --help``.
 
 ^^^^^^^
 Testing
@@ -123,7 +124,7 @@ are wrong, you can provide the names yourself by overriding
 
 .. code-block:: python
 
-   import_modules = ["PyQt5"]
+   import_modules = ['PyQt5']
 
 
 These tests often catch missing dependencies and non-RPATHed

lib/spack/docs/build_systems/sourceforgepackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

lib/spack/docs/build_systems/wafpackage.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -62,8 +63,8 @@ run package-specific unit tests.
 .. code-block:: python
 
    def installtest(self):
-       with working_dir("test"):
+       with working_dir('test'):
-           pytest = which("py.test")
+           pytest = which('py.test')
            pytest()
 
 
@@ -92,7 +93,7 @@ the following dependency automatically:
 
 .. code-block:: python
 
-   depends_on("python@2.5:", type="build")
+   depends_on('python@2.5:', type='build')
 
 
 Waf only supports Python 2.5 and up.
@@ -112,7 +113,7 @@ phase, you can use:
        args = []
 
        if self.run_tests:
-           args.append("--test")
+           args.append('--test')
 
        return args
 

lib/spack/docs/chain.rst

@@ -1,17 +1,17 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 .. 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
+you can add it as an entry to ``upstreams.yaml``:
-:ref:`configuration-scopes`:
 
 .. code-block:: yaml
 
@@ -22,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
+Spack base directory.
-in :ref:`config.yaml <config-yaml>`.
 
 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

@@ -1,4 +1,5 @@
-# Copyright Spack Project Developers. See COPYRIGHT file for details.
+# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -47,6 +48,9 @@
 os.environ["COLIFY_SIZE"] = "25x120"
 os.environ["COLUMNS"] = "120"
 
+# Generate full package list if needed
+subprocess.call(["spack", "list", "--format=html", "--update=package_list.html"])
+
 # Generate a command index if an update is needed
 subprocess.call(
     [
@@ -93,7 +97,9 @@ class PatchedPythonDomain(PythonDomain):
     def resolve_xref(self, env, fromdocname, builder, typ, target, node, contnode):
         if "refspecific" in node:
             del node["refspecific"]
-        return super().resolve_xref(env, fromdocname, builder, typ, target, node, contnode)
+        return super(PatchedPythonDomain, self).resolve_xref(
+            env, fromdocname, builder, typ, target, node, contnode
+        )
 
 
 #
@@ -198,37 +204,19 @@ 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"),
-    ("py:class", "llnl.util.lang.KT"),
-    ("py:class", "llnl.util.lang.VT"),
-    ("py:class", "llnl.util.lang.ClassPropertyType"),
-    ("py:obj", "llnl.util.lang.KT"),
-    ("py:obj", "llnl.util.lang.VT"),
-    ("py:obj", "llnl.util.lang.ClassPropertyType"),
 ]
 
 # The reST default role (used for this markup: `text`) to use for all documents.

lib/spack/docs/config_yaml.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -25,23 +26,14 @@ These settings can be overridden in ``etc/spack/config.yaml`` or
 The location where Spack will install packages and their dependencies.
 Default is ``$spack/opt/spack``.
 
----------------
+---------------------------------------------------
-``projections``
+``install_hash_length`` and ``install_path_scheme``
----------------
+---------------------------------------------------
 
-.. warning::
+The default Spack installation path can be very long and can create problems
-
+for scripts with hardcoded shebangs. Additionally, when using the Intel
-   Modifying projections of the install tree is strongly discouraged.
+compiler, and if there is also a long list of dependencies, the compiler may
-
+segfault. If you see the following:
-By default Spack installs all packages into a unique directory relative to the install
-tree root with the following layout:
-
-.. code-block::
-
-   {architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}
-
-In very rare cases, it may be necessary to reduce the length of this path. For example,
-very old versions of the Intel compiler are known to segfault when input paths are too long:
 
      .. code-block:: console
 
@@ -49,25 +41,36 @@ very old versions of the Intel compiler are known to segfault when input paths a
        ** Segmentation violation signal raised. **
        Access violation or stack overflow. Please contact Intel Support for assistance.
 
-Another case is Python and R packages with many runtime dependencies, which can result
+it may be because variables containing dependency specs may be too long. There
-in very large ``PYTHONPATH`` and ``R_LIBS`` environment variables. This can cause the
+are two parameters to help with long path names. Firstly, the
-``execve`` system call to fail with ``E2BIG``, preventing processes from starting.
+``install_hash_length`` parameter can set the length of the hash in the
+installation path from 1 to 32. The default path uses the full 32 characters.
 
-For this reason, Spack allows users to modify the installation layout through custom
+Secondly, it is also possible to modify the entire installation
-projections. For example
+scheme. By default Spack uses
+``{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}``
+where the tokens that are available for use in this directive are the
+same as those understood by the :meth:`~spack.spec.Spec.format`
+method. Using this parameter it is possible to use a different package
+layout or reduce the depth of the installation paths. For example
 
      .. code-block:: yaml
 
        config:
-         install_tree:
+         install_path_scheme: '{name}/{version}/{hash:7}'
-           root: $spack/opt/spack
-           projections:
-             all: "{name}/{version}/{hash:16}"
 
-would install packages into sub-directories using only the package name, version and a
+would install packages into sub-directories using only the package
-hash length of 16 characters.
+name, version and a hash length of 7 characters.
 
-Notice that reducing the hash length increases the likelihood of hash collisions.
+When using either parameter to set the hash length it only affects the
+representation of the hash in the installation directory. You
+should be aware that the smaller the hash length the more likely
+naming conflicts will occur. These parameters are independent of those
+used to configure module names.
+
+.. warning:: Modifying the installation hash length or path scheme after
+   packages have been installed will prevent Spack from being
+   able to find the old installation directories.
 
 --------------------
 ``build_stage``
@@ -125,8 +128,6 @@ are stored in ``$spack/var/spack/cache``.  These are stored indefinitely
 by default. Can be purged with :ref:`spack clean --downloads
 <cmd-spack-clean>`.
 
-.. _Misc Cache:
-
 --------------------
 ``misc_cache``
 --------------------
@@ -144,26 +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 additional ``curl`` arguments are required,
-they can be set in the config, e.g. ``url_fetch_method:'curl -k -q'``.
-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``
 --------------------
@@ -311,78 +292,14 @@ It is also worth noting that:
          non_bindable_shared_objects = ["libinterface.so"]
 
 ----------------------
-``install_status``
+``terminal_title``
 ----------------------
 
-When set to ``true``, Spack will show information about its current progress
+By setting this option to ``true``, Spack will update the terminal's title to
-as well as the current and total package numbers. Progress is shown both
+provide information about its current progress as well as the current and
-in the terminal title and inline. Setting it to ``false`` will not show any
+total package numbers.
-progress information.
 
 To work properly, this requires your terminal to reset its title after
 Spack has finished its work, otherwise Spack's status information will
 remain in the terminal's title indefinitely. Most terminals should already
 be set up this way and clear Spack's status information.
-
------------
-``aliases``
------------
-
-Aliases can be used to define new Spack commands. They can be either shortcuts
-for longer commands or include specific arguments for convenience. For instance,
-if users want to use ``spack install``'s ``-v`` argument all the time, they can
-create a new alias called ``inst`` that will always call ``install -v``:
-
-.. code-block:: yaml
-
-   aliases:
-     inst: install -v
-
--------------------------------
-``concretization_cache:enable``
--------------------------------
-
-When set to ``true``, Spack will utilize a cache of solver outputs from
-successful concretization runs. When enabled, Spack will check the concretization
-cache prior to running the solver. If a previous request to solve a given
-problem is present in the cache, Spack will load the concrete specs and other
-solver data from the cache rather than running the solver. Specs not previously
-concretized will be added to the cache on a successful solve. The cache additionally
-holds solver statistics, so commands like ``spack solve`` will still return information
-about the run that produced a given solver result.
-
-This cache is a subcache of the :ref:`Misc Cache` and as such will be cleaned when the Misc
-Cache is cleaned.
-
-When ``false`` or ommitted, all concretization requests will be performed from scatch
-
-----------------------------
-``concretization_cache:url``
-----------------------------
-
-Path to the location where Spack will root the concretization cache. Currently this only supports
-paths on the local filesystem.
-
-Default location is under the :ref:`Misc Cache` at: ``$misc_cache/concretization``
-
-------------------------------------
-``concretization_cache:entry_limit``
-------------------------------------
-
-Sets a limit on the number of concretization results that Spack will cache. The limit is evaluated
-after each concretization run; if Spack has stored more results than the limit allows, the
-oldest concretization results are pruned until 10% of the limit has been removed.
-
-Setting this value to 0 disables the automatic pruning. It is expected users will be
-responsible for maintaining this cache.
-
------------------------------------
-``concretization_cache:size_limit``
------------------------------------
-
-Sets a limit on the size of the concretization cache in bytes. The limit is evaluated
-after each concretization run; if Spack has stored more results than the limit allows, the
-oldest concretization results are pruned until 10% of the limit has been removed.
-
-Setting this value to 0 disables the automatic pruning. It is expected users will be
-responsible for maintaining this cache.

lib/spack/docs/configuration.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -11,13 +12,12 @@ Configuration Files
 Spack has many configuration files.  Here is a quick list of them, in
 case you want to skip directly to specific docs:
 
-* :ref:`packages.yaml <compiler-config>`
+* :ref:`compilers.yaml <compiler-config>`
 * :ref:`concretizer.yaml <concretizer-options>`
 * :ref:`config.yaml <config-yaml>`
-* :ref:`include.yaml <include-yaml>`
 * :ref:`mirrors.yaml <mirrors>`
 * :ref:`modules.yaml <modules>`
-* :ref:`packages.yaml <packages-config>`
+* :ref:`packages.yaml <build-settings>`
 * :ref:`repos.yaml <repositories>`
 
 You can also add any of these as inline configuration in the YAML
@@ -46,12 +46,6 @@ Each Spack configuration file is nested under a top-level section
 corresponding to its name. So, ``config.yaml`` starts with ``config:``,
 ``mirrors.yaml`` starts with ``mirrors:``, etc.
 
-.. tip::
-
-   Validation and autocompletion of Spack config files can be enabled in
-   your editor with the YAML language server. See `spack/schemas
-   <https://github.com/spack/schemas>`_ for more information.
-
 .. _configuration-scopes:
 
 --------------------
@@ -79,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
@@ -101,7 +92,7 @@ are six configuration scopes. From lowest to highest:
    precedence over all other scopes.
 
 Each configuration directory may contain several configuration files,
-such as ``config.yaml``, ``packages.yaml``, or ``mirrors.yaml``.  When
+such as ``config.yaml``, ``compilers.yaml``, or ``mirrors.yaml``.  When
 configurations conflict, settings from higher-precedence scopes override
 lower-precedence settings.
 
@@ -205,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:
 
 ------------------------
@@ -287,15 +239,13 @@ 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).
 
-There are also special notations for string concatenation and precendense override:
+There are also special notations for string concatenation and precendense override.
-
+Using the ``+:`` notation  can be used to force *prepending* strings or lists. For lists, this is identical
-* ``+:`` will force *prepending* strings or lists. For lists, this is the default behavior.
+to the default behavior. Using the ``-:`` works similarly, but for *appending* values.
-* ``-:`` works similarly, but for *appending* values.
-
 :ref:`config-prepend-append`
 
 ^^^^^^^^^^^
@@ -517,7 +467,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

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -8,98 +9,24 @@
 Container Images
 ================
 
-Spack :ref:`environments` can easily be turned into container images. This page
+Spack :ref:`environments` are a great tool to create container images, but
-outlines two ways in which this can be done:
+preparing one that is suitable for production requires some more boilerplate
-
+than just:
-1. By installing the environment on the host system, and copying the installations
-   into the container image. This approach does not require any tools like Docker
-   or Singularity to be installed.
-2. By generating a Docker or Singularity recipe that can be used to build the
-   container image. In this approach, Spack builds the software inside the
-   container runtime, not on the host system.
-
-The first approach is easiest if you already have an installed environment,
-the second approach gives more control over the container image.
-
----------------------------
-From existing installations
----------------------------
-
-If you already have a Spack environment installed on your system, you can
-share the binaries as an OCI compatible container image. To get started you
-just have to configure and OCI registry and run ``spack buildcache push``.
-
-.. code-block:: console
-  
-   # Create and install an environment in the current directory
-   spack env create -d .
-   spack -e . add pkg-a pkg-b
-   spack -e . install
-
-   # Configure the registry
-   spack -e . mirror add --oci-username-variable REGISTRY_USER \
-                         --oci-password-variable REGISTRY_TOKEN \
-                        container-registry oci://example.com/name/image
-
-   # Push the image (do set REGISTRY_USER and REGISTRY_TOKEN)
-   spack -e . buildcache push --update-index --base-image ubuntu:22.04 --tag my_env container-registry
-
-The resulting container image can then be run as follows:
-
-.. code-block:: console
-
-   $ docker run -it example.com/name/image:my_env
-
-The image generated by Spack consists of the specified base image with each package from the
-environment as a separate layer on top. The image is minimal by construction, it only contains the
-environment roots and its runtime dependencies.
-
-.. note::
-
-  When using registries like GHCR and Docker Hub, the ``--oci-password`` flag is not
-  the password for your account, but a personal access token you need to generate separately.
-
-The specified ``--base-image`` should have a libc that is compatible with the host system.
-For example if your host system is Ubuntu 20.04, you can use ``ubuntu:20.04``, ``ubuntu:22.04``
-or newer: the libc in the container image must be at least the version of the host system,
-assuming ABI compatibility. It is also perfectly fine to use a completely different
-Linux distribution as long as the libc is compatible.
-
-For convenience, Spack also turns the OCI registry into a :ref:`build cache <binary_caches_oci>`,
-so that future ``spack install`` of the environment will simply pull the binaries from the
-registry instead of doing source builds. The flag ``--update-index`` is needed to make Spack
-take the build cache into account when concretizing.
-
-.. note::
-
-  When generating container images in CI, the approach above is recommended when CI jobs
-  already run in a sandboxed environment. You can simply use ``spack`` directly
-  in the CI job and push the resulting image to a registry. Subsequent CI jobs should
-  run faster because Spack can install from the same registry instead of rebuilding from
-  sources.
-
----------------------------------------------
-Generating recipes for Docker and Singularity
----------------------------------------------
-
-Apart from copying existing installations into container images, Spack can also
-generate recipes for container images. This is useful if you want to run Spack
-itself in a sandboxed environment instead of on the host system.
-
-Since recipes need a little bit more boilerplate than
 
 .. code-block:: docker
 
    COPY spack.yaml /environment
    RUN spack -e /environment install
 
-Spack provides a command to generate customizable recipes for container images. Customizations
+Additional actions may be needed to minimize the size of the
-include minimizing the size of the image, installing packages in the base image using the system
+container, or to update the system software that is installed in the base
-package manager, and setting up a proper entrypoint to run the image.
+image, or to set up a proper entrypoint to run the image. These tasks are
+usually both necessary and repetitive, so Spack comes with a command
+to generate recipes for container images starting from a ``spack.yaml``.
 
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 A Quick Introduction
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 Consider having a Spack environment like the following:
 
@@ -110,8 +37,8 @@ Consider having a Spack environment like the following:
      - gromacs+mpi
      - mpich
 
-Producing a ``Dockerfile`` from it is as simple as changing directories to
+Producing a ``Dockerfile`` from it is as simple as moving to the directory
-where the ``spack.yaml`` file is stored and running the following command:
+where the ``spack.yaml`` file is stored and giving the following command:
 
 .. code-block:: console
 
@@ -177,9 +104,9 @@ configuration are discussed in details in the sections below.
 
 .. _container_spack_images:
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 Spack Images on Docker Hub
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Docker images with Spack preinstalled and ready to be used are
 built when a release is tagged, or nightly on ``develop``. The images
@@ -195,44 +122,27 @@ 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
+   * - CentOS 7
-     - ``ubuntu:24.04``
+     - ``centos:7``
-     - ``spack/ubuntu-noble``
+     - ``spack/centos7``
-   * - CentOS Stream9
+   * - CentOS Stream
-     - ``quay.io/centos/centos:stream9``
+     - ``quay.io/centos/centos:stream``
-     - ``spack/centos-stream9``
+     - ``spack/centos-stream``
    * - openSUSE Leap
      - ``opensuse/leap``
      - ``spack/leap15``
    * - Amazon Linux 2
      - ``amazonlinux:2``
      - ``spack/amazon-linux``
-   * - AlmaLinux 8
-     - ``almalinux:8``
-     - ``spack/almalinux8``
-   * - AlmaLinux 9
-     - ``almalinux:9``
-     - ``spack/almalinux9``
-   * - Rocky Linux 8
-     - ``rockylinux:8``
-     - ``spack/rockylinux8``
-   * - Rocky Linux 9
-     - ``rockylinux:9``
-     - ``spack/rockylinux9``
-   * - Fedora Linux 39
-     - ``fedora:39``
-     - ``spack/fedora39``
-   * - Fedora Linux 40
-     - ``fedora:40``
-     - ``spack/fedora40``
-
-
 
 All the images are tagged with the corresponding release of Spack:
 
@@ -246,9 +156,9 @@ by Spack use them as default base images for their ``build`` stage,
 even though handles to use custom base images provided by users are
 available to accommodate complex use cases.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
-Configuring the Container Recipe
+Creating Images From Environments
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 Any Spack Environment can be used for the automatic generation of container
 recipes. Sensible defaults are provided for things like the base image or the
@@ -282,25 +192,31 @@ under the ``container`` attribute of environments:
          final:
          - libgomp
 
+       # Extra instructions
+       extra_instructions:
+         final: |
+           RUN echo 'export PS1="\[$(tput bold)\]\[$(tput setaf 1)\][gromacs]\[$(tput setaf 2)\]\u\[$(tput sgr0)\]:\w $ "' >> ~/.bashrc
+
        # Labels for the image
        labels:
          app: "gromacs"
          mpi: "mpich"
 
-A detailed description of the options available can be found in the :ref:`container_config_options` section.
+A detailed description of the options available can be found in the
+:ref:`container_config_options` section.
 
-~~~~~~~~~~~~~~~~~~~
+-------------------
 Setting Base Images
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 The ``images`` subsection is used to select both the image where
 Spack builds the software and the image where the built software
 is installed. This attribute can be set in different ways and
 which one to use depends on the use case at hand.
 
-""""""""""""""""""""""""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Use Official Spack Images From Dockerhub
-""""""""""""""""""""""""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To generate a recipe that uses an official Docker image from the
 Spack organization to build the software and the corresponding official OS image
@@ -505,9 +421,9 @@ responsibility to ensure that:
 Therefore we don't recommend its use in cases that can be otherwise
 covered by the simplified mode shown first.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 Singularity Definition Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 In addition to producing recipes in ``Dockerfile`` format Spack can produce
 Singularity Definition Files by just changing the value of the ``format``
@@ -528,9 +444,9 @@ attribute:
 The minimum version of Singularity required to build a SIF (Singularity Image Format)
 image from the recipes generated by Spack is ``3.5.3``.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 Extending the Jinja2 Templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 The Dockerfile and the Singularity definition file that Spack can generate are based on
 a few Jinja2 templates that are rendered according to the environment being containerized.
@@ -589,13 +505,6 @@ the example below:
    COPY data /share/myapp/data
    {% endblock %}
 
-The Dockerfile is generated by running:
-
-.. code-block:: console
-
-   $ spack -e /opt/environment containerize
-
-Note that the environment must be active for spack to read the template.
 The recipe that gets generated contains the two extra instruction that we added in our template extension:
 
 .. code-block:: Dockerfile
@@ -651,9 +560,9 @@ The recipe that gets generated contains the two extra instruction that we added
 
 .. _container_config_options:
 
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 Configuration Reference
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 The tables below describe all the configuration options that are currently supported
 to customize the generation of container recipes:
@@ -750,13 +659,13 @@ to customize the generation of container recipes:
      - Description string
      - No
 
-~~~~~~~~~~~~~~
+--------------
 Best Practices
-~~~~~~~~~~~~~~
+--------------
 
-"""
+^^^
 MPI
-"""
+^^^
 Due to the dependency on Fortran for OpenMPI, which is the spack default
 implementation, consider adding ``gfortran`` to the ``apt-get install`` list.
 
@@ -767,9 +676,9 @@ For execution on HPC clusters, it can be helpful to import the docker
 image into Singularity in order to start a program with an *external*
 MPI. Otherwise, also add ``openssh-server`` to the ``apt-get install`` list.
 
-""""
+^^^^
 CUDA
-""""
+^^^^
 Starting from CUDA 9.0, Nvidia provides minimal CUDA images based on
 Ubuntu. Please see `their instructions <https://hub.docker.com/r/nvidia/cuda/>`_.
 Avoid double-installing CUDA by adding, e.g.
@@ -788,9 +697,9 @@ to your ``spack.yaml``.
 Users will either need ``nvidia-docker`` or e.g. Singularity to *execute*
 device kernels.
 
-"""""""""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^^^^^^^
 Docker on Windows and OSX
-"""""""""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 On Mac OS and Windows, docker runs on a hypervisor that is not allocated much
 memory by default, and some spack packages may fail to build due to lack of

lib/spack/docs/contribution_guide.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -183,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
@@ -309,219 +310,53 @@ Once all of the dependencies are installed, you can try building the documentati
    $ make clean
    $ make
 
-If you see any warning or error messages, you will have to correct those before your PR
+If you see any warning or error messages, you will have to correct those before
-is accepted. If you are editing the documentation, you should be running the
+your PR is accepted.
-documentation tests to make sure there are no errors. Documentation changes can result
-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:
+If you are editing the documentation, you should obviously be running the
+documentation tests. But even if you are simply adding a new package, your
+changes could cause the documentation tests to fail:
 
-^^^^^^^^^
+.. code-block:: console
-GitLab CI
-^^^^^^^^^
 
-""""""""""""""""""
+   package_list.rst:8745: WARNING: Block quote ends without a blank line; unexpected unindent.
-Build Cache Stacks
-""""""""""""""""""
 
-Spack welcomes the contribution of software stacks of interest to the community. These
+At first, this error message will mean nothing to you, since you didn't edit
-stacks are used to test package recipes and generate publicly available build caches.
+that file. Until you look at line 8745 of the file in question:
-Spack uses GitLab CI for managing the orchestration of build jobs.
 
-GitLab Entry Point
+.. code-block:: rst
-~~~~~~~~~~~~~~~~~~
 
-Add stack entrypoint to the ``share/spack/gitlab/cloud_pipelines/.gitlab-ci.yml``. There
+   Description:
-are two stages required for each new stack, the generation stage and the build stage.
+      NetCDF is a set of software libraries and self-describing, machine-
+     independent data formats that support the creation, access, and sharing
+     of array-oriented scientific data.
 
-The generate stage is defined using the job template ``.generate`` configured with
+Our documentation includes :ref:`a list of all Spack packages <package-list>`.
-environment variables defining the name of the stack in ``SPACK_CI_STACK_NAME`` and the
+If you add a new package, its docstring is added to this page. The problem in
-platform (``SPACK_TARGET_PLATFORM``) and architecture (``SPACK_TARGET_ARCH``) configuration,
+this case was that the docstring looked like:
-and the tags associated with the class of runners to build on.
 
-.. note::
+.. code-block:: python
 
-    The ``SPACK_CI_STACK_NAME`` must match the name of the directory containing the
+   class Netcdf(Package):
-    stacks ``spack.yaml``.
+       """
+       NetCDF is a set of software libraries and self-describing,
+       machine-independent data formats that support the creation,
+       access, and sharing of array-oriented scientific data.
+       """
 
+Docstrings cannot start with a newline character, or else Sphinx will complain.
+Instead, they should look like:
 
-.. note::
+.. code-block:: python
 
-    The platform and architecture variables are specified in order to select the
+   class Netcdf(Package):
-    correct configurations from the generic configurations used in Spack CI. The
+       """NetCDF is a set of software libraries and self-describing,
-    configurations currently available are:
+       machine-independent data formats that support the creation,
+       access, and sharing of array-oriented scientific data."""
 
-    * ``.cray_rhel_zen4``
+Documentation changes can result in much more obfuscated warning messages.
-    * ``.cray_sles_zen4``
+If you don't understand what they mean, feel free to ask when you submit
-    * ``.darwin_aarch64``
+your PR.
-    * ``.darwin_x86_64``
-    * ``.linux_aarch64``
-    * ``.linux_icelake``
-    * ``.linux_neoverse_n1``
-    * ``.linux_neoverse_v1``
-    * ``.linux_neoverse_v2``
-    * ``.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

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -177,8 +178,12 @@ Spec-related modules
   Contains :class:`~spack.spec.Spec`. Also implements most of the logic for concretization
   of specs.
 
-:mod:`spack.spec_parser`
+:mod:`spack.parser`
-  Contains :class:`~spack.spec_parser.SpecParser` and functions related to parsing specs.
+  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
@@ -332,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.
+Spack defines hooks by way of a module at ``lib/spack/spack/hooks`` where we can define
-This module has to be registered in ``__init__.py`` so that Spack is aware of it.
+types of hooks in the ``__init__.py``, and then python files in that folder
-This section will cover the basic kind of hooks, and how to write them.
+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
@@ -348,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.
+A ``pre_install`` hook is run within an install subprocess, directly before
-It expects a single argument of a spec.
+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,
+A ``post_install`` hook is run within an install subprocess, directly after
-but before the build stage is removed and the spec is registered in the database. It expects two
+the install finishes, but before the build stage is removed. If you
-arguments: spec and an optional boolean indicating whether this spec is being installed explicitly.
+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.
 
 
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -543,11 +620,11 @@ With either interpreter you can run a single command:
 
 .. code-block:: console
 
-   $ spack python -c 'from spack.concretize import concretize_one; concretize_one("python")'
+   $ spack python -c 'import distro; distro.linux_distribution()'
-   ...
+   ('Ubuntu', '18.04', 'Bionic Beaver')
 
-   $ spack python -i ipython -c 'from spack.concretize import concretize_one; concretize_one("python")'
+   $ spack python -i ipython -c 'import distro; distro.linux_distribution()'
-   Out[1]: ...
+   Out[1]: ('Ubuntu', '18.04', 'Bionic Beaver')
 
 or a file:
 
@@ -707,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
+<major-releases>` (``0.17.0``, ``0.18.0``, etc.) and :ref:`point releases
-<patch-releases>` (``0.22.1``, ``0.22.2``, ``0.22.3``, etc.). Here is a
+<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
     |/
@@ -738,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.18`` has ``0.18.x`` versions of Spack, and
-``releases/v0.21`` has ``v0.21.x`` versions. A major release is the first
+``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``.
@@ -769,40 +846,27 @@ for more details.
 Scheduling work for releases
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-We schedule work for **major releases** through `milestones
+We schedule work for releases by creating `GitHub projects
-<https://github.com/spack/spack/milestones>`_ and `GitHub Projects
+<https://github.com/spack/spack/projects>`_. At any time, there may be
-<https://github.com/spack/spack/projects>`_, while **patch releases** use `labels
+several open release projects. For example, below are two releases (from
-<https://github.com/spack/spack/labels>`_.
+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
+.. image:: images/projects.png
-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.
 
-Bug reports in GitHub issues are automatically labelled ``bug`` and ``triage``. Spack developers
+This image shows one release in progress for ``0.15.1`` and another for
-assign one of the labels ``impact-low``, ``impact-medium`` or ``impact-high``. This will make the
+``0.16.0``. Each of these releases has a project board containing issues
-issue appear in the `Triaged bugs <https://github.com/orgs/spack/projects/6>`_ project board.
+and pull requests. GitHub shows a status bar with completed work in
-Important issues should be assigned to the next milestone as well, so they appear at the top of
+green, work in progress in purple, and work not started yet in gray, so
-the project board.
+it's fairly easy to see progress.
 
-Spack's milestones are not firm commitments so we move work between releases frequently. If we
+Spack's project boards are not firm commitments so we move work between
-need to make a release and some tasks are not yet done, we will simply move them to the next major
+releases frequently. If we need to make a release and some tasks are not
-release milestone, rather than delaying the release to complete them.
+yet done, we will simply move them to the next minor or major release, rather
+than delaying the release to complete them.
 
-^^^^^^^^^^^^^^^^^^^^^
+For more on using GitHub project boards, see `GitHub's documentation
-Backporting bug fixes
+<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:
 
@@ -810,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
+Assuming a project board has already been created and all required work
-are:
+completed, the steps to make the major release are:
 
-#. `Create a new milestone <https://github.com/spack/spack/milestones>`_ for the next major
+#. Create two new project boards:
-   release.
 
-#. `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``
@@ -860,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
+   For instance when you have just released ``v0.15.0``, set the version
-   to ``(0, 24, 0, 'dev0')`` on ``develop``.
+   to ``(0, 16, 0, 'dev0')`` on ``develop``.
 
 #. Follow the steps in :ref:`publishing-releases`.
 
@@ -870,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*
+Assuming a project board has already been created and all required work
-which contains cherry-picked commits from the ``develop`` branch. The majority of the work is to
+completed, the steps to make the point release are:
-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.
 
-The backports pull request is always titled ``Backports vX.Y.Z`` and is labelled ``backports``. It
+#. Create a new project board for the next point release.
-is opened from a branch named ``backports/vX.Y.Z`` and targets the ``releases/vX.Y`` branch.
 
-Whenever a pull request labelled ``vX.Y.Z`` is merged, cherry-pick the associated squashed commit
+#. Move any optional tasks that are not done to the next project board.
-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.
 
-.. warning::
+#. Check out the release branch (it should already exist).
 
-   Sometimes you may **still** get merge conflicts even if you have
+    For the ``X.Y.Z`` release, the release branch is called ``releases/vX.Y``.
-   cherry-picked all the commits in order. This generally means there
+    For ``v0.15.1``, you would check out ``releases/v0.15``:
-   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 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
+      $ git checkout releases/v0.15
-      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.
 
-When all commits are cherry-picked in the ``backports/vX.Y.Z`` branch, make the patch
+#. If a pull request to the release branch named ``Backports vX.Y.Z`` is not already
-release as follows:
+   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
+#. Cherry-pick each pull request in the ``Done`` column of the release
-   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
+   .. image:: images/pr-commit.png
-   ``backports/vX.Y.Z`` branch, that both bumps the Spack version number and updates the changelog:
+
+   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.
@@ -924,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
+   If CI does not pass, you'll need to figure out why, and make changes
-   is needed to keep track in the release branch of all the commits that were
+   to the release branch until it does. You can make more commits, modify
-   cherry-picked.
+   or remove cherry-picked commits, or cherry-pick **more** from
-
+   ``develop`` to make this happen.
-#. 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.
 
 #. Follow the steps in :ref:`publishing-releases`.
 
@@ -1014,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
+* 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.22.3``.
+  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.
+The ``--force`` argument to ``git tag`` makes ``git`` overwrite the existing
-
+``releases/latest`` tag with the new one.
-.. 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.
 
 
 .. _announcing-releases:
@@ -1049,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/env_vars_yaml.rst

@@ -1,34 +0,0 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-.. _env-vars-yaml:
-
-=============================================
-Environment Variable Settings (env_vars.yaml)
-=============================================
-
-Spack allows you to include shell environment variable modifications
-for a spack environment by including an ``env_vars.yaml``.  Environment
-varaibles can be modified by setting, unsetting, appending, and prepending
-variables in the shell environment.
-The changes to the shell environment will take effect when the spack
-environment is activated.
-
-for example,
-
-.. code-block:: yaml
-
-  env_vars:
-    set:
-      ENVAR_TO_SET_IN_ENV_LOAD: "FOO"
-    unset:
-      ENVAR_TO_UNSET_IN_ENV_LOAD:
-    prepend_path:
-      PATH_LIST: "path/to/prepend"
-    append_path:
-      PATH_LIST: "path/to/append"
-    remove_path:
-      PATH_LIST: "path/to/remove"
-
-

lib/spack/docs/example_files/spack.yaml

@@ -0,0 +1,161 @@
+spack:
+  definitions:
+  - compiler-pkgs:
+    - 'llvm+clang@6.0.1 os=centos7'
+    - 'gcc@6.5.0 os=centos7'
+    - 'llvm+clang@6.0.1 os=ubuntu18.04'
+    - 'gcc@6.5.0 os=ubuntu18.04'
+  - pkgs:
+    - readline@7.0
+    # - xsdk@0.4.0
+  - compilers:
+    - '%gcc@5.5.0'
+    - '%gcc@6.5.0'
+    - '%gcc@7.3.0'
+    - '%clang@6.0.0'
+    - '%clang@6.0.1'
+  - oses:
+    - os=ubuntu18.04
+    - os=centos7
+
+  specs:
+  - matrix:
+    - [$pkgs]
+    - [$compilers]
+    - [$oses]
+    exclude:
+      - '%gcc@7.3.0 os=centos7'
+      - '%gcc@5.5.0 os=ubuntu18.04'
+
+  mirrors:
+    cloud_gitlab: https://mirror.spack.io
+
+  compilers:
+    # The .gitlab-ci.yml for this project picks a Docker container which does
+    # not have any compilers pre-built and ready to use, so we need to fake the
+    # existence of those here.
+    - compiler:
+        operating_system: centos7
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: gcc@5.5.0
+        target: x86_64
+    - compiler:
+        operating_system: centos7
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: gcc@6.5.0
+        target: x86_64
+    - compiler:
+        operating_system: centos7
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: clang@6.0.0
+        target: x86_64
+    - compiler:
+        operating_system: centos7
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: clang@6.0.1
+        target: x86_64
+
+    - compiler:
+        operating_system: ubuntu18.04
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: clang@6.0.0
+        target: x86_64
+    - compiler:
+        operating_system: ubuntu18.04
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: clang@6.0.1
+        target: x86_64
+    - compiler:
+        operating_system: ubuntu18.04
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: gcc@6.5.0
+        target: x86_64
+    - compiler:
+        operating_system: ubuntu18.04
+        modules: []
+        paths:
+          cc: /not/used
+          cxx: /not/used
+          f77: /not/used
+          fc: /not/used
+        spec: gcc@7.3.0
+        target: x86_64
+
+  gitlab-ci:
+    bootstrap:
+      - name: compiler-pkgs
+        compiler-agnostic: true
+    mappings:
+      - # spack-cloud-ubuntu
+        match:
+          # these are specs, if *any* match the spec under consideration, this
+          # 'mapping' will be used to generate the CI job
+          - os=ubuntu18.04
+        runner-attributes:
+          # 'tags' and 'image' go directly onto the job, 'variables' will
+          # be added to what we already necessarily create for the job as
+          # a part of the CI workflow
+          tags:
+            - spack-k8s
+          image:
+            name: scottwittenburg/spack_builder_ubuntu_18.04
+            entrypoint: [""]
+      - # spack-cloud-centos
+        match:
+          # these are specs, if *any* match the spec under consideration, this
+          # 'mapping' will be used to generate the CI job
+          - 'os=centos7'
+        runner-attributes:
+          tags:
+            - spack-k8s
+          image:
+            name: scottwittenburg/spack_builder_centos_7
+            entrypoint: [""]
+
+  cdash:
+    build-group: Release Testing
+    url: http://cdash
+    project: Spack Testing
+    site: Spack Docker-Compose Workflow
+
+  repos: []
+  upstreams: {}
+  modules:
+    enable: []
+  packages: {}
+  config: {}

lib/spack/docs/extensions.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
@@ -8,42 +9,46 @@
 Custom Extensions
 =================
 
-*Spack extensions* allow you to extend Spack capabilities by deploying your
+*Spack extensions* permit you to extend Spack capabilities by deploying your
 own custom commands or logic in an arbitrary location on your filesystem.
 This might be extremely useful e.g. to develop and maintain a command whose purpose is
 too specific to be considered for reintegration into the mainline or to
 evolve a command through its early stages before starting a discussion to merge
 it upstream.
-
 From Spack's point of view an extension is any path in your filesystem which
-respects the following naming and layout for files:
+respects a prescribed naming and layout for files:
 
 .. code-block:: console
 
   spack-scripting/ # The top level directory must match the format 'spack-{extension_name}'
   ├── pytest.ini # Optional file if the extension ships its own tests
   ├── scripting # Folder that may contain modules that are needed for the extension commands
-  │   ├── cmd # Folder containing extension commands
+  │   └── cmd # Folder containing extension commands
-  │   │   └── filter.py # A new command that will be available
+  │       └── filter.py # A new command that will be available
-  │   └── functions.py # Module with internal details
+  ├── tests # Tests for this extension
-  └── tests # Tests for this extension
   │   ├── conftest.py
   │   └── test_filter.py
   └── templates # Templates that may be needed by the extension
 
-In the example above, the extension is named *scripting*. It adds an additional command
+In the example above the extension named *scripting* adds an additional command (``filter``)
-(``spack filter``) and unit tests to verify its behavior.
+and unit tests to verify its behavior. The code for this example can be
+obtained by cloning the corresponding git repository:
 
-The extension can import any core Spack module in its implementation. When loaded by
+.. TODO: write an ad-hoc "hello world" extension and make it part of the spack organization
-the ``spack`` command, the extension itself is imported as a Python package in the
-``spack.extensions`` namespace. In the example above, since the extension is named
-"scripting", the corresponding Python module is ``spack.extensions.scripting``.
-
-The code for this example extension can be obtained by cloning the corresponding git repository:
 
 .. code-block:: console
 
-   $ git -C /tmp clone https://github.com/spack/spack-scripting.git
+   $ cd ~/
+   $ mkdir tmp && cd tmp
+   $ git clone https://github.com/alalazo/spack-scripting.git
+   Cloning into 'spack-scripting'...
+   remote: Counting objects: 11, done.
+   remote: Compressing objects: 100% (7/7), done.
+   remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0
+   Receiving objects: 100% (11/11), done.
+
+As you can see by inspecting the sources, Python modules that are part of the extension
+can import any core Spack module.
 
 ---------------------------------
 Configure Spack to Use Extensions
@@ -56,7 +61,7 @@ paths to ``config.yaml``. In the case of our example this means ensuring that:
 
    config:
      extensions:
-     - /tmp/spack-scripting
+     - ~/tmp/spack-scripting
 
 is part of your configuration file. Once this is setup any command that the extension provides
 will be available from the command line:
@@ -81,68 +86,37 @@ will be available from the command line:
      --implicit       select specs that are not installed or were installed implicitly
      --output OUTPUT  where to dump the result
 
-The corresponding unit tests can be run giving the appropriate options to ``spack unit-test``:
+The corresponding unit tests can be run giving the appropriate options
+to ``spack unit-test``:
 
 .. code-block:: console
 
    $ spack unit-test --extension=scripting
-   ========================================== test session starts ===========================================
+
-   platform linux -- Python 3.11.5, pytest-7.4.3, pluggy-1.3.0
+   ============================================================== test session starts ===============================================================
-   rootdir: /home/culpo/github/spack-scripting
+   platform linux2 -- Python 2.7.15rc1, pytest-3.2.5, py-1.4.34, pluggy-0.4.0
-   configfile: pytest.ini
+   rootdir: /home/mculpo/tmp/spack-scripting, inifile: pytest.ini
-   testpaths: tests
-   plugins: xdist-3.5.0
    collected 5 items
 
-   tests/test_filter.py .....                                                                         [100%]
+   tests/test_filter.py ...XX
+   ============================================================ short test summary info =============================================================
+   XPASS tests/test_filter.py::test_filtering_specs[flags3-specs3-expected3]
+   XPASS tests/test_filter.py::test_filtering_specs[flags4-specs4-expected4]
 
-   ========================================== slowest 30 durations ==========================================
+   =========================================================== slowest 20 test durations ============================================================
-   2.31s setup    tests/test_filter.py::test_filtering_specs[kwargs0-specs0-expected0]
+   3.74s setup    tests/test_filter.py::test_filtering_specs[flags0-specs0-expected0]
-   0.57s call     tests/test_filter.py::test_filtering_specs[kwargs2-specs2-expected2]
+   0.17s call     tests/test_filter.py::test_filtering_specs[flags3-specs3-expected3]
-   0.56s call     tests/test_filter.py::test_filtering_specs[kwargs4-specs4-expected4]
+   0.16s call     tests/test_filter.py::test_filtering_specs[flags2-specs2-expected2]
-   0.54s call     tests/test_filter.py::test_filtering_specs[kwargs3-specs3-expected3]
+   0.15s call     tests/test_filter.py::test_filtering_specs[flags1-specs1-expected1]
-   0.54s call     tests/test_filter.py::test_filtering_specs[kwargs1-specs1-expected1]
+   0.13s call     tests/test_filter.py::test_filtering_specs[flags4-specs4-expected4]
-   0.48s call     tests/test_filter.py::test_filtering_specs[kwargs0-specs0-expected0]
+   0.08s call     tests/test_filter.py::test_filtering_specs[flags0-specs0-expected0]
-   0.01s setup    tests/test_filter.py::test_filtering_specs[kwargs4-specs4-expected4]
+   0.04s teardown tests/test_filter.py::test_filtering_specs[flags4-specs4-expected4]
-   0.01s setup    tests/test_filter.py::test_filtering_specs[kwargs2-specs2-expected2]
+   0.00s setup    tests/test_filter.py::test_filtering_specs[flags4-specs4-expected4]
-   0.01s setup    tests/test_filter.py::test_filtering_specs[kwargs1-specs1-expected1]
+   0.00s setup    tests/test_filter.py::test_filtering_specs[flags3-specs3-expected3]
-   0.01s setup    tests/test_filter.py::test_filtering_specs[kwargs3-specs3-expected3]
+   0.00s setup    tests/test_filter.py::test_filtering_specs[flags1-specs1-expected1]
-
+   0.00s setup    tests/test_filter.py::test_filtering_specs[flags2-specs2-expected2]
-   (5 durations < 0.005s hidden.  Use -vv to show these durations.)
+   0.00s teardown tests/test_filter.py::test_filtering_specs[flags2-specs2-expected2]
-   =========================================== 5 passed in 5.06s ============================================
+   0.00s teardown tests/test_filter.py::test_filtering_specs[flags1-specs1-expected1]
-
+   0.00s teardown tests/test_filter.py::test_filtering_specs[flags0-specs0-expected0]
----------------------------------------
+   0.00s teardown tests/test_filter.py::test_filtering_specs[flags3-specs3-expected3]
-Registering Extensions via Entry Points
+   ====================================================== 3 passed, 2 xpassed in 4.51 seconds =======================================================
----------------------------------------
-
-.. 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/features.rst

@@ -1,4 +1,5 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
+.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
+   Spack Project Developers. See the top-level COPYRIGHT file for details.
 
    SPDX-License-Identifier: (Apache-2.0 OR MIT)
 

lib/spack/docs/frequently_asked_questions.rst

@@ -1,90 +0,0 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-==========================
-Frequently Asked Questions
-==========================
-
-This page contains answers to frequently asked questions about Spack.
-If you have questions that are not answered here, feel free to ask on
-`Slack <https://slack.spack.io>`_ or `GitHub Discussions
-<https://github.com/spack/spack/discussions>`_. If you've learned the
-answer to a question that you think should be here, please consider
-contributing to this page.
-
-.. _faq-concretizer-precedence:
-
------------------------------------------------------
-Why does Spack pick particular versions and variants?
------------------------------------------------------
-
-This question comes up in a variety of forms:
-
- 1. Why does Spack seem to ignore my package preferences from ``packages.yaml`` config?
- 2. Why does Spack toggle a variant instead of using the default from the ``package.py`` file?
-
-The short answer is that Spack always picks an optimal configuration
-based on a complex set of criteria\ [#f1]_. These criteria are more nuanced
-than always choosing the latest versions or default variants.
-
-.. note::
-
-    As a rule of thumb: requirements + constraints > strong preferences > reuse > preferences > defaults.
-
-The following set of criteria (from lowest to highest precedence) explain
-common cases where concretization output may seem surprising at first.
-
-1. :ref:`Package preferences <package-preferences>` configured in ``packages.yaml``
-   override variant defaults from ``package.py`` files, and influence the optimal
-   ordering of versions. Preferences are specified as follows:
-
-   .. code-block:: yaml
-
-      packages:
-        foo:
-          version: [1.0, 1.1]
-          variants: ~mpi
-
-2. :ref:`Reuse concretization <concretizer-options>` configured in ``concretizer.yaml``
-   overrides preferences, since it's typically faster to reuse an existing spec than to
-   build a preferred one from sources. When build caches are enabled, specs may be reused
-   from a remote location too. Reuse concretization is configured as follows:
-
-   .. code-block:: yaml
-
-      concretizer:
-        reuse: dependencies  # other options are 'true' and 'false'
-
-3. :ref:`Strong preferences <package-strong-preferences>` configured in ``packages.yaml``
-   are higher priority than reuse, and can be used to strongly prefer a specific version
-   or variant, without erroring out if it's not possible. Strong preferences are specified
-   as follows:
-
-   .. code-block:: yaml
-
-      packages:
-        foo:
-          prefer:
-          - "@1.1: ~mpi"
-
-4. :ref:`Package requirements <package-requirements>` configured in ``packages.yaml``,
-   and constraints from the command line as well as ``package.py`` files override all
-   of the above. Requirements are specified as follows:
-
-   .. code-block:: yaml
-
-      packages:
-        foo:
-          require:
-          - "@1.2: +mpi"
-          conflicts:
-          - "@1.4"
-
-Requirements and constraints restrict the set of possible solutions, while reuse
-behavior and preferences influence what an optimal solution looks like.
-
-
-.. rubric:: Footnotes
-
-.. [#f1] The exact list of criteria can be retrieved with the ``spack solve`` command

lib/spack/docs/gpu_configuration.rst

@@ -1,135 +0,0 @@
-.. Copyright Spack Project Developers. See COPYRIGHT file for details.
-
-   SPDX-License-Identifier: (Apache-2.0 OR MIT)
-
-==========================
-Using External GPU Support
-==========================
-
-Many packages come with a ``+cuda`` or ``+rocm`` variant. With no added
-configuration Spack will download and install the needed components.
-It may be preferable to use existing system support: the following sections
-help with using a system installation of GPU libraries.
-
------------------------------------
-Using an External ROCm Installation
------------------------------------
-
-Spack breaks down ROCm into many separate component packages. The following
-is an example ``packages.yaml`` that organizes a consistent set of ROCm
-components for use by dependent packages:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       variants: amdgpu_target=gfx90a
-     hip:
-       buildable: false
-       externals:
-       - spec: hip@5.3.0
-         prefix: /opt/rocm-5.3.0/hip
-     hsa-rocr-dev:
-       buildable: false
-       externals:
-       - spec: hsa-rocr-dev@5.3.0
-         prefix: /opt/rocm-5.3.0/
-     llvm-amdgpu:
-       buildable: false
-       externals:
-       - spec: llvm-amdgpu@5.3.0
-         prefix: /opt/rocm-5.3.0/llvm/
-     comgr:
-       buildable: false
-       externals:
-       - spec: comgr@5.3.0
-         prefix: /opt/rocm-5.3.0/
-     hipsparse:
-       buildable: false
-       externals:
-       - spec: hipsparse@5.3.0
-         prefix: /opt/rocm-5.3.0/
-     hipblas:
-       buildable: false
-       externals:
-       - spec: hipblas@5.3.0
-         prefix: /opt/rocm-5.3.0/
-     rocblas:
-       buildable: false
-       externals:
-       - spec: rocblas@5.3.0
-         prefix: /opt/rocm-5.3.0/
-     rocprim:
-       buildable: false
-       externals:
-       - spec: rocprim@5.3.0
-         prefix: /opt/rocm-5.3.0/rocprim/
-
-This is in combination with the following compiler definition:
-
-.. code-block:: yaml
-
-   packages:
-     llvm-amdgpu:
-       externals:
-       - spec: llvm-amdgpu@=5.3.0
-         prefix: /opt/rocm-5.3.0
-         compilers:
-           c: /opt/rocm-5.3.0/bin/amdclang
-           cxx: /opt/rocm-5.3.0/bin/amdclang++
-           fortran: null
-
-This includes the following considerations:
-
-- Each of the listed externals specifies ``buildable: false`` to force Spack
-  to use only the externals we defined.
-- ``spack external find`` can automatically locate some of the ``hip``/``rocm``
-  packages, but not all of them, and furthermore not in a manner that
-  guarantees a complementary set if multiple ROCm installations are available.
-- The ``prefix`` is the same for several components, but note that others
-  require listing one of the subdirectories as a prefix.
-
------------------------------------
-Using an External CUDA Installation
------------------------------------
-
-CUDA is split into fewer components and is simpler to specify:
-
-.. code-block:: yaml
-
-   packages:
-     all:
-       variants:
-       - cuda_arch=70
-     cuda:
-       buildable: false
-       externals:
-       - spec: cuda@11.0.2
-         prefix: /opt/cuda/cuda-11.0.2/
-
-where ``/opt/cuda/cuda-11.0.2/lib/`` contains ``libcudart.so``.
-
-
-
------------------------------------
-Using an External OpenGL API
------------------------------------
-Depending on whether we have a graphics card or not, we may choose to use OSMesa or GLX to implement the OpenGL API.
-
-If a graphics card is unavailable, OSMesa is recommended and can typically be built with Spack.
-However, if we prefer to utilize the system GLX tailored to our graphics card, we need to declare it as an external. Here's how to do it:
-
-
-.. code-block:: yaml
-
-  packages:
-    libglx:
-      require: [opengl]
-    opengl:
-      buildable: false
-      externals:
-      - prefix: /usr/
-        spec: opengl@4.6
-
-Note that prefix has to be the root of both the libraries and the headers, using is /usr not the path the the lib.
-To know which spec for opengl is available use ``cd /usr/include/GL && grep -Ri gl_version``.