perl: remove a few imports

Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>

.flake8

@@ -28,7 +28,7 @@ max-line-length = 99
 # - F821: undefined name `name`
 #
 per-file-ignores =
-  var/spack/repos/*/package.py:F403,F405,F821
+  var/spack/*/package.py:F403,F405,F821
   *-ci-package.py:F403,F405,F821
 
 # exclude things we usually do not want linting for.

.github/workflows/ci.yaml

@@ -42,17 +42,17 @@ jobs:
           # built-in repository or documentation
           filters: |
             bootstrap:
-            - 'var/spack/repos/builtin/packages/clingo-bootstrap/**'
-            - '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/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/clingo-bootstrap/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/clingo/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/python/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/re2c/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/gnupg/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/libassuan/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/libgcrypt/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/libgpg-error/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/libksba/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/npth/**'
+            - 'var/spack/repos/spack_repo/builtin/packages/pinentry/**'
             - 'lib/spack/**'
             - 'share/spack/**'
             - '.github/workflows/bootstrap.yml'

.github/workflows/import-check.yaml

@@ -6,6 +6,7 @@ on:
 jobs:
   # Check we don't make the situation with circular imports worse
   import-check:
+    continue-on-error: true
     runs-on: ubuntu-latest
     steps:
     - uses: julia-actions/setup-julia@v2

.github/workflows/prechecks.yml

@@ -34,7 +34,7 @@ jobs:
         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
+        vermin --backport importlib --backport argparse --violations --backport typing -t=3.6- -vvv var/spack/repos var/spack/test_repos
 
   # Run style checks on the files that have been changed
   style:
@@ -65,7 +65,11 @@ jobs:
       python_version: '3.13'
 
   verify-checksums:
-    if: ${{ inputs.with_packages == 'true' }}
+    # do not run if the commit message or PR description contains [skip-verify-checksums]
+    if: >-
+      ${{ inputs.with_packages == 'true' &&
+      !contains(github.event.pull_request.body, '[skip-verify-checksums]') &&
+      !contains(github.event.head_commit.message, '[skip-verify-checksums]') }}
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29

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

@@ -5,4 +5,4 @@ isort==6.0.1
 mypy==1.15.0
 types-six==1.17.0.20250403
 vermin==1.6.0
-pylint==3.3.6
+pylint==3.3.7

.github/workflows/sync-packages.yaml

@@ -0,0 +1,37 @@
+name: sync with spack/spack-packages
+
+on:
+  push:
+    branches:
+    - develop
+
+jobs:
+  sync:
+    if: github.repository == 'spack/spack'
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout spack/spack
+      run: git clone https://github.com/spack/spack.git
+    - name: Checkout spack/spack-packages
+      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      with:
+        ssh-key: ${{ secrets.SYNC_PACKAGES_KEY }}
+        path: spack-packages
+        repository: spack/spack-packages
+    - name: Install git-filter-repo
+      run: |
+        curl -LfsO https://raw.githubusercontent.com/newren/git-filter-repo/refs/tags/v2.47.0/git-filter-repo
+        echo "67447413e273fc76809289111748870b6f6072f08b17efe94863a92d810b7d94  git-filter-repo" | sha256sum -c -
+        chmod +x git-filter-repo
+        sudo mv git-filter-repo /usr/local/bin/
+    - name: Sync spack/spack-packages with spack/spack
+      run: |
+        cd spack-packages
+        git-filter-repo --quiet --source ../spack \
+                        --path var/spack/repos/ --path-rename var/spack/repos/:python/ \
+                        --path share/spack/gitlab/cloud_pipelines/ --path-rename share/spack/gitlab/cloud_pipelines/:.ci/gitlab/ \
+                        --refs develop
+    - name: Push
+      run: |
+        cd spack-packages
+        git push git@github.com:spack/spack-packages.git develop:develop --force

etc/spack/defaults/repos.yaml

@@ -11,4 +11,4 @@
 #   ~/.spack/repos.yaml
 # -------------------------------------------------------------------------
 repos:
-  - $spack/var/spack/repos/builtin
+  - $spack/var/spack/repos/spack_repo/builtin

lib/spack/docs/basic_usage.rst

@@ -276,7 +276,7 @@ remove dependent packages *before* removing their dependencies or use the
 Garbage collection
 ^^^^^^^^^^^^^^^^^^
 
-When Spack builds software from sources, if often installs tools that are needed
+When Spack builds software from sources, it often installs tools that are needed
 just to build or test other software. These are not necessary at runtime.
 To support cases where removing these tools can be a benefit Spack provides
 the ``spack gc`` ("garbage collector") command, which will uninstall all unneeded packages:
@@ -1916,7 +1916,7 @@ diagnostics. Issues, if found, are reported to stdout:
    PKG-DIRECTIVES: 1 issue found
    1. lammps: wrong variant in "conflicts" directive
        the variant 'adios' does not exist
-       in /home/spack/spack/var/spack/repos/builtin/packages/lammps/package.py
+       in /home/spack/spack/var/spack/repos/spack_repo/builtin/packages/lammps/package.py
 
 
 ------------

lib/spack/docs/binary_caches.rst

@@ -45,10 +45,14 @@ provided binary cache, which can be a local directory or a remote URL.
 Here is an example where a build cache is created in a local directory named
 "spack-cache", to which we push the "ninja" spec:
 
+ninja-1.12.1-vmvycib6vmiofkdqgrblo7zsvp7odwut
+
 .. code-block:: console
 
     $ spack buildcache push ./spack-cache ninja
-    ==> Pushing binary packages to file:///home/spackuser/spack/spack-cache/build_cache
+    ==> Selected 30 specs to push to file:///home/spackuser/spack/spack-cache
+    ...
+    ==> [30/30] Pushed ninja@1.12.1/ngldn2k
 
 Note that ``ninja`` must be installed locally for this to work.
 
@@ -85,7 +89,7 @@ You can see that the mirror is added with ``spack mirror list`` as follows:
     spack-public       https://spack-llnl-mirror.s3-us-west-2.amazonaws.com/
 
 
-At this point, you've create a buildcache, but spack hasn't indexed it, so if
+At this point, you've created a buildcache, but Spack hasn't indexed it, so if
 you run ``spack buildcache list`` you won't see any results. You need to index
 this new build cache as follows:
 
@@ -98,9 +102,10 @@ Now you can use list:
 .. code-block:: console
 
     $  spack buildcache list
-    ==> 1 cached build.
-    -- linux-ubuntu20.04-skylake / gcc@9.3.0 ------------------------
-    ninja@1.10.2
+    ==> 24 cached builds.
+    -- linux-ubuntu22.04-sapphirerapids / gcc@12.3.0 ----------------
+    [ ... ]
+    ninja@1.12.1
 
 With ``mymirror`` configured and an index available, Spack will automatically
 use it during concretization and installation. That means that you can expect
@@ -111,17 +116,17 @@ verify by re-installing ninja:
 
     $ spack uninstall ninja
     $ spack install ninja
-    ==> Installing ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-    ==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spec.json.sig
-    gpg: Signature made Do 12 Jan 2023 16:01:04 CET
-    gpg:                using RSA key 61B82B2B2350E171BD17A1744E3A689061D57BF6
+    [ ... ]
+    ==> Installing ninja-1.12.1-ngldn2kpvb6lqc44oqhhow7fzg7xu7lh [24/24]
+    gpg: Signature made Thu 06 Mar 2025 10:03:38 AM MST
+    gpg:                using RSA key 75BC0528114909C076E2607418010FFAD73C9B07
     gpg: Good signature from "example (GPG created for Spack) <example@example.com>" [ultimate]
-    ==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.10.2/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spack
-    ==> Extracting ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz from binary cache
-    ==> ninja: Successfully installed ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-    Search: 0.00s.  Fetch: 0.17s.  Install: 0.12s.  Total: 0.29s
-    [+] /home/harmen/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
-
+    ==> Fetching file:///home/spackuser/spack/spack-cache/blobs/sha256/f0/f08eb62661ad159d2d258890127fc6053f5302a2f490c1c7f7bd677721010ee0
+    ==> Fetching file:///home/spackuser/spack/spack-cache/blobs/sha256/c7/c79ac6e40dfdd01ac499b020e52e57aa91151febaea3ad183f90c0f78b64a31a
+    ==> Extracting ninja-1.12.1-ngldn2kpvb6lqc44oqhhow7fzg7xu7lh from binary cache
+    ==> ninja: Successfully installed ninja-1.12.1-ngldn2kpvb6lqc44oqhhow7fzg7xu7lh
+      Search: 0.00s.  Fetch: 0.11s.  Install: 0.11s.  Extract: 0.10s.  Relocate: 0.00s.  Total: 0.22s
+    [+] /home/spackuser/spack/opt/spack/linux-ubuntu22.04-sapphirerapids/gcc-12.3.0/ninja-1.12.1-ngldn2kpvb6lqc44oqhhow7fzg7xu7lh
 
 It worked! You've just completed a full example of creating a build cache with
 a spec of interest, adding it as a mirror, updating its index, listing the contents,
@@ -313,7 +318,7 @@ 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
+    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/>`_.
 
@@ -344,19 +349,18 @@ which lets you get started quickly. See the following resources for more informa
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Create tarball of installed Spack package and all dependencies.
-Tarballs are checksummed and signed if gpg2 is available.
-Places them in a directory ``build_cache`` that can be copied to a mirror.
-Commands like ``spack buildcache install`` will search Spack mirrors for build_cache to get the list of build caches.
+Tarballs and specfiles are compressed and checksummed, manifests are signed if gpg2 is available.
+Commands like ``spack buildcache install`` will search Spack mirrors to get the list of build caches.
 
 ==============  ========================================================================================================================
 Arguments       Description
 ==============  ========================================================================================================================
 ``<specs>``     list of partial specs or hashes with a leading ``/`` to match from installed packages and used for creating build caches
-``-d <path>``   directory in which ``build_cache`` directory is created, defaults to ``.``
-``-f``          overwrite ``.spack`` file in ``build_cache`` directory if it exists
+``-d <path>``   directory in which ``v3`` and ``blobs`` directories are created, defaults to ``.``
+``-f``          overwrite compressed tarball and spec metadata files if they already exist
 ``-k <key>``    the key to sign package with. In the case where multiple keys exist, the package will be unsigned unless ``-k`` is used.
 ``-r``          make paths in binaries relative before creating tarball
-``-y``          answer yes to all create unsigned ``build_cache`` questions
+``-y``          answer yes to all questions about creating unsigned build caches
 ==============  ========================================================================================================================
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -397,6 +401,165 @@ List public keys available on Spack mirror.
 =========  ==============================================
 Arguments  Description
 =========  ==============================================
-``-i``     trust the keys downloaded with prompt for each
+``-it``    trust the keys downloaded with prompt for each
 ``-y``     answer yes to all trust all keys downloaded
 =========  ==============================================
+
+.. _build_cache_layout:
+
+------------------
+Build Cache Layout
+------------------
+
+This section describes the structure and content of URL-style build caches, as
+distinguished from OCI-style build caches.
+
+The entry point for a binary package is a manifest json file that points to at
+least two other files stored as content-addressed blobs. These files include a spec
+metadata file, as well as the installation directory of the package stored as
+a compressed archive file. Binary package manifest files are named to indicate
+the package name and version, as well as the hash of the concrete spec. For
+example::
+
+  gcc-runtime-12.3.0-qyu2lvgt3nxh7izxycugdbgf5gsdpkjt.spec.manifest.json
+
+would contain the manifest for a binary package of ``gcc-runtime@12.3.0``.
+The id of the built package is defined to be the DAG hash of the concrete spec,
+and exists in the name of the file as well. The id distinguishes a particular
+binary package from all other binary packages with the same package name and
+version. Below is an example binary package manifest file. Such a file would
+live in the versioned spec manifests directory of a binary mirror, for example
+``v3/manifests/spec/``::
+
+  {
+    "version": 3,
+    "data": [
+      {
+        "contentLength": 10731083,
+        "mediaType": "application/vnd.spack.install.v2.tar+gzip",
+        "compression": "gzip",
+        "checksumAlgorithm": "sha256",
+        "checksum": "0f24aa6b5dd7150067349865217acd3f6a383083f9eca111d2d2fed726c88210"
+      },
+      {
+        "contentLength": 1000,
+        "mediaType": "application/vnd.spack.spec.v5+json",
+        "compression": "gzip",
+        "checksumAlgorithm": "sha256",
+        "checksum": "fba751c4796536737c9acbb718dad7429be1fa485f5585d450ab8b25d12ae041"
+      }
+    ]
+  }
+
+The manifest points to both the compressed tar file as well as the compressed
+spec metadata file, and contains the checksum of each. This checksum
+is also used as the address of the associated file, and hence, must be
+known in order to locate the tarball or spec file within the mirror. Once the
+tarball or spec metadata file is downloaded, the checksum should be computed locally
+and compared to the checksum in the manifest to ensure the contents have not changed
+since the binary package was pushed. Spack stores all data files (including compressed
+tar files, spec metadata, indices, public keys, etc) within a ``blobs/<hash-algorithm>/``
+directory, using the first two characters of the checksum as a sub-directory
+to reduce the number files in a single folder.  Here is a depiction of the
+organization of binary mirror contents::
+
+  mirror_directory/
+    v3/
+      layout.json
+      manifests/
+        spec/
+          gcc-runtime/
+            gcc-runtime-12.3.0-s2nqujezsce4x6uhtvxscu7jhewqzztx.spec.manifest.json
+          gmake/
+            gmake-4.4.1-lpr4j77rcgkg5536tmiuzwzlcjsiomph.spec.manifest.json
+          compiler-wrapper/
+            compiler-wrapper-1.0-s7ieuyievp57vwhthczhaq2ogowf3ohe.spec.manifest.json
+        index/
+          index.manifest.json
+        key/
+          75BC0528114909C076E2607418010FFAD73C9B07.key.manifest.json
+          keys.manifest.json
+    blobs/
+      sha256/
+        0f/
+          0f24aa6b5dd7150067349865217acd3f6a383083f9eca111d2d2fed726c88210
+        fb/
+          fba751c4796536737c9acbb718dad7429be1fa485f5585d450ab8b25d12ae041
+        2a/
+          2a21836d206ccf0df780ab0be63fdf76d24501375306a35daa6683c409b7922f
+        ...
+
+Files within the ``manifests`` directory are organized into subdirectories by
+the type of entity they represent. Binary package manifests live in the ``spec/``
+directory, binary cache index manifests live in the ``index/`` directory, and
+manifests for public keys and their indices live in the ``key/`` subdirectory.
+Regardless of the type of entity they represent, all manifest files are named
+with an extension ``.manifest.json``.
+
+Every manifest contains a ``data`` array, each element of which refers to an
+associated file stored a content-addressed blob.  Considering the example spec
+manifest shown above, the compressed installation archive can be found by
+picking out the data blob with the appropriate ``mediaType``, which in this
+case would be ``application/vnd.spack.install.v1.tar+gzip``. The associated
+file is found by looking in the blobs directory under ``blobs/sha256/fb/`` for
+the file named with the complete checksum value.
+
+As mentioned above, every entity in a binary mirror (aka build cache) is stored
+as a content-addressed blob pointed to by a manifest. While an example spec
+manifest (i.e. a manifest for a binary package) is shown above, here is what
+the manifest of a build cache index looks like::
+
+  {
+    "version": 3,
+    "data": [
+      {
+        "contentLength": 6411,
+        "mediaType": "application/vnd.spack.db.v8+json",
+        "compression": "none",
+        "checksumAlgorithm": "sha256",
+        "checksum": "225a3e9da24d201fdf9d8247d66217f5b3f4d0fc160db1498afd998bfd115234"
+      }
+    ]
+  }
+
+Some things to note about this manifest are that it points to a blob that is not
+compressed (``compression: "none"``), and that the ``mediaType`` is one we have
+not seen yet, ``application/vnd.spack.db.v8+json``. The decision not to compress
+build cache indices stems from the fact that spack does not yet sign build cache
+index manifests. Once that changes, you may start to see these indices stored as
+compressed blobs.
+
+For completeness, here are examples of manifests for the other two types of entities
+you might find in a spack build cache. First a public key manifest::
+
+  {
+    "version": 3,
+    "data": [
+      {
+        "contentLength": 2472,
+        "mediaType": "application/pgp-keys",
+        "compression": "none",
+        "checksumAlgorithm": "sha256",
+        "checksum": "9fc18374aebc84deb2f27898da77d4d4410e5fb44c60c6238cb57fb36147e5c7"
+      }
+    ]
+  }
+
+Note the ``mediaType`` of ``application/pgp-keys``. Finally, a public key index manifest::
+
+  {
+    "version": 3,
+    "data": [
+      {
+        "contentLength": 56,
+        "mediaType": "application/vnd.spack.keyindex.v1+json",
+        "compression": "none",
+        "checksumAlgorithm": "sha256",
+        "checksum": "29b3a0eb6064fd588543bc43ac7d42d708a69058dafe4be0859e3200091a9a1c"
+      }
+    ]
+  }
+
+Again note the ``mediaType`` of ``application/vnd.spack.keyindex.v1+json``. Also note
+that both the above manifest examples refer to uncompressed blobs, this is for the same
+reason spack does not yet compress build cache index blobs.

lib/spack/docs/bootstrapping.rst

@@ -14,7 +14,7 @@ is an entire command dedicated to the management of every aspect of bootstrappin
 
 .. command-output:: spack bootstrap --help
 
-Spack is configured to bootstrap its dependencies lazily by default; i.e. the first time they are needed and
+Spack is configured to bootstrap its dependencies lazily by default; i.e., the first time they are needed and
 can't be found. You can readily check if any prerequisite for using Spack is missing by running:
 
 .. code-block:: console
@@ -36,8 +36,8 @@ can't be found. You can readily check if any prerequisite for using Spack is mis
 
 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
-dependencies are missing the return code is ``1``, otherwise ``0``. Running a command that
+they can be bootstrapped. The return code of this command summarizes the results; if any
+dependencies are missing, the return code is ``1``, otherwise ``0``. Running a command that
 concretizes a spec, like:
 
 .. code-block:: console

lib/spack/docs/build_systems.rst

@@ -66,7 +66,7 @@ on these ideas for each distinct build system that Spack supports:
    build_systems/rocmpackage
    build_systems/sourceforgepackage
 
-For reference, the :py:mod:`Build System API docs <spack.build_systems>`
+For reference, the :py:mod:`Build System API docs <spack_repo.builtin.build_systems>`
 provide a list of build systems and methods/attributes that can be
 overridden. If you are curious about the implementation of a particular
 build system, you can view the source code by running:
@@ -83,14 +83,14 @@ packages. You can quickly find examples by running:
 
 .. code-block:: console
 
-   $ cd var/spack/repos/builtin/packages
+   $ cd var/spack/repos/spack_repo/builtin/packages
    $ grep -l QMakePackage */package.py
 
 
 You can then view these packages with ``spack edit``.
 
 This guide is intended to supplement the
-:py:mod:`Build System API docs <spack.build_systems>` with examples of
+:py:mod:`Build System API docs <spack_repo.builtin.build_systems>` with examples of
 how to override commonly used methods. It also provides rules of thumb
 and suggestions for package developers who are unfamiliar with a
 particular build system.

lib/spack/docs/build_systems/bundlepackage.rst

@@ -27,10 +27,10 @@ it could use the ``require`` directive as follows:
 
 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>`_
+* `AmdAocl <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/amd_aocl/package.py>`_
+* `EcpProxyApps <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/ecp_proxy_apps/package.py>`_
+* `Libc <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/libc/package.py>`_
+* `Xsdk <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/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/cmakepackage.rst

@@ -129,8 +129,8 @@ Adding flags to cmake
 To add additional flags to the ``cmake`` call, simply override the
 ``cmake_args`` function. The following example defines values for the flags
 ``WHATEVER``, ``ENABLE_BROKEN_FEATURE``, ``DETECT_HDF5``, and ``THREADS`` with
-and without the :meth:`~spack.build_systems.cmake.CMakeBuilder.define` and
-:meth:`~spack.build_systems.cmake.CMakeBuilder.define_from_variant` helper functions:
+and without the :meth:`~spack_repo.builtin.build_systems.cmake.CMakeBuilder.define` and
+:meth:`~spack_repo.builtin.build_systems.cmake.CMakeBuilder.define_from_variant` helper functions:
 
 .. code-block:: python
 
@@ -199,7 +199,7 @@ a variant to control this:
 However, not every CMake package accepts all four of these options.
 Grep the ``CMakeLists.txt`` file to see if the default values are
 missing or replaced. For example, the
-`dealii <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py>`_
+`dealii <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/dealii/package.py>`_
 package overrides the default variant with:
 
 .. code-block:: python

lib/spack/docs/build_systems/custompackage.rst

@@ -20,8 +20,8 @@ start is to look at the definitions of other build systems. This guide
 focuses mostly on how Spack's build systems work.
 
 In this guide, we will be using the
-`perl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/perl/package.py>`_ and
-`cmake <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cmake/package.py>`_
+`perl <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/perl/package.py>`_ and
+`cmake <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/cmake/package.py>`_
 packages as examples. ``perl``'s build system is a hand-written
 ``Configure`` shell script, while ``cmake`` bootstraps itself during
 installation. Both of these packages require custom build systems.

lib/spack/docs/build_systems/makefilepackage.rst

@@ -96,9 +96,9 @@ there are any other variables you need to set, you can do this in the
        env.set("BLASLIB", spec["blas"].libs.ld_flags)
 
 
-`cbench <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cbench/package.py>`_
+`cbench <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/cbench/package.py>`_
 is a good example of a simple package that does this, while
-`esmf <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/esmf/package.py>`_
+`esmf <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/esmf/package.py>`_
 is a good example of a more complex package.
 
 """"""""""""""""""""""
@@ -129,7 +129,7 @@ If you do need access to the spec, you can create a property like so:
        ]
 
 
-`cloverleaf <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cloverleaf/package.py>`_
+`cloverleaf <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/cloverleaf/package.py>`_
 is a good example of a package that uses this strategy.
 
 """""""""""""
@@ -152,7 +152,7 @@ and a ``filter`` method to help with this. For example:
        makefile.filter(r"^\s*FC\s*=.*",  f"FC = {spack_fc}")
 
 
-`stream <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/stream/package.py>`_
+`stream <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/stream/package.py>`_
 is a good example of a package that involves editing a Makefile to set
 the appropriate variables.
 
@@ -192,7 +192,7 @@ well for storing variables:
                inc.write(f"{key} = {config[key]}\n")
 
 
-`elk <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/elk/package.py>`_
+`elk <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/elk/package.py>`_
 is a good example of a package that uses a dictionary to store
 configuration variables.
 
@@ -213,7 +213,7 @@ them in a list:
                inc.write(f"{var}\n")
 
 
-`hpl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/hpl/package.py>`_
+`hpl <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/hpl/package.py>`_
 is a good example of a package that uses a list to store
 configuration variables.
 

lib/spack/docs/build_systems/rpackage.rst

@@ -39,7 +39,7 @@ for "CRAN <package-name>" and you should quickly find what you want.
 If it isn't on CRAN, try Bioconductor, another common R repository.
 
 For the purposes of this tutorial, we will be walking through
-`r-caret <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/r-caret/package.py>`_
+`r-caret <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/r_caret/package.py>`_
 as an example. If you search for "CRAN caret", you will quickly find what
 you are looking for at https://cran.r-project.org/package=caret.
 https://cran.r-project.org is the main CRAN website. However, CRAN also
@@ -337,7 +337,7 @@ Non-R dependencies
 ^^^^^^^^^^^^^^^^^^
 
 Some packages depend on non-R libraries for linking. Check out the
-`r-stringi <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/r-stringi/package.py>`_
+`r-stringi <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/r_stringi/package.py>`_
 package for an example: https://cloud.r-project.org/package=stringi.
 If you search for the text "SystemRequirements", you will see:
 
@@ -352,7 +352,7 @@ Passing arguments to the installation
 
 Some R packages provide additional flags that can be passed to
 ``R CMD INSTALL``, often to locate non-R dependencies.
-`r-rmpi <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/r-rmpi/package.py>`_
+`r-rmpi <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/r_rmpi/package.py>`_
 is an example of this, and flags for linking to an MPI library. To pass
 these to the installation command, you can override ``configure_args``
 like so:

lib/spack/docs/build_systems/sconspackage.rst

@@ -104,10 +104,10 @@ Finding available options
 
 The first place to start when looking for a list of valid options to
 build a package is ``scons --help``. Some packages like
-`kahip <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/kahip/package.py>`_
+`kahip <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/kahip/package.py>`_
 don't bother overwriting the default SCons help message, so this isn't
 very useful, but other packages like
-`serf <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/serf/package.py>`_
+`serf <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/serf/package.py>`_
 print a list of valid command-line variables:
 
 .. code-block:: console
@@ -177,7 +177,7 @@ print a list of valid command-line variables:
 
 
 More advanced packages like
-`cantera <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cantera/package.py>`_
+`cantera <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/cantera/package.py>`_
 use ``scons --help`` to print a list of subcommands:
 
 .. code-block:: console

lib/spack/docs/conf.py

@@ -35,8 +35,8 @@
 if not os.path.exists(link_name):
     os.symlink(os.path.abspath("../../.."), link_name, target_is_directory=True)
 sys.path.insert(0, os.path.abspath("_spack_root/lib/spack/external"))
-sys.path.insert(0, os.path.abspath("_spack_root/lib/spack/external/_vendoring"))
 sys.path.append(os.path.abspath("_spack_root/lib/spack/"))
+sys.path.append(os.path.abspath("_spack_root/var/spack/repos/"))
 
 # Add the Spack bin directory to the path so that we can use its output in docs.
 os.environ["SPACK_ROOT"] = os.path.abspath("_spack_root")
@@ -76,11 +76,20 @@
     apidoc_args
     + [
         "_spack_root/lib/spack/spack",
+        "_spack_root/lib/spack/spack/package.py",  # sphinx struggles with os.chdir re-export.
         "_spack_root/lib/spack/spack/test/*.py",
         "_spack_root/lib/spack/spack/test/cmd/*.py",
     ]
 )
 sphinx_apidoc(apidoc_args + ["_spack_root/lib/spack/llnl"])
+sphinx_apidoc(
+    apidoc_args
+    + [
+        "--implicit-namespaces",
+        "_spack_root/var/spack/repos/spack_repo",
+        "_spack_root/var/spack/repos/spack_repo/builtin/packages",
+    ]
+)
 
 # Enable todo items
 todo_include_todos = True
@@ -209,7 +218,7 @@ def setup(sphinx):
     # 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_repo.builtin.build_systems._checks.BuilderWithDefaults"),
     # Spack classes that intersphinx is unable to resolve
     ("py:class", "spack.version.StandardVersion"),
     ("py:class", "spack.spec.DependencySpec"),
@@ -219,16 +228,20 @@ def setup(sphinx):
     ("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", "_vendoring.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.K"),
+    ("py:class", "llnl.util.lang.V"),
     ("py:class", "llnl.util.lang.ClassPropertyType"),
     ("py:obj", "llnl.util.lang.KT"),
     ("py:obj", "llnl.util.lang.VT"),
     ("py:obj", "llnl.util.lang.ClassPropertyType"),
+    ("py:obj", "llnl.util.lang.K"),
+    ("py:obj", "llnl.util.lang.V"),
 ]
 
 # The reST default role (used for this markup: `text`) to use for all documents.

lib/spack/docs/config_yaml.rst

@@ -148,8 +148,8 @@ 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.
+Path to custom certificates for SSL verification. The value can be a
+filesystem 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.

lib/spack/docs/containers.rst

@@ -11,7 +11,7 @@ Container Images
 Spack :ref:`environments` can easily be turned into container images. This page
 outlines two ways in which this can be done:
 
-1. By installing the environment on the host system, and copying the installations
+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
@@ -56,8 +56,8 @@ 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.
+  When using registries like GHCR and Docker Hub, the ``--oci-password`` flag specifies not
+  the password for your account, but rather 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``

lib/spack/docs/contribution_guide.rst

@@ -226,9 +226,9 @@ If all is well, you'll see something like this:
 
    Modified files:
 
-     var/spack/repos/builtin/packages/hdf5/package.py
-     var/spack/repos/builtin/packages/hdf/package.py
-     var/spack/repos/builtin/packages/netcdf/package.py
+     var/spack/repos/spack_repo/builtin/packages/hdf5/package.py
+     var/spack/repos/spack_repo/builtin/packages/hdf/package.py
+     var/spack/repos/spack_repo/builtin/packages/netcdf/package.py
    =======================================================
    Flake8 checks were clean.
 
@@ -236,9 +236,9 @@ However, if you aren't compliant with PEP 8, flake8 will complain:
 
 .. code-block:: console
 
-   var/spack/repos/builtin/packages/netcdf/package.py:26: [F401] 'os' imported but unused
-   var/spack/repos/builtin/packages/netcdf/package.py:61: [E303] too many blank lines (2)
-   var/spack/repos/builtin/packages/netcdf/package.py:106: [E501] line too long (92 > 79 characters)
+   var/spack/repos/spack_repo/builtin/packages/netcdf/package.py:26: [F401] 'os' imported but unused
+   var/spack/repos/spack_repo/builtin/packages/netcdf/package.py:61: [E303] too many blank lines (2)
+   var/spack/repos/spack_repo/builtin/packages/netcdf/package.py:106: [E501] line too long (92 > 79 characters)
    Flake8 found errors.
 
 Most of the error messages are straightforward, but if you don't understand what
@@ -280,7 +280,7 @@ All of these can be installed with Spack, e.g.
 
 .. warning::
 
-   Sphinx has `several required dependencies <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/py-sphinx/package.py>`_.
+   Sphinx has `several required dependencies <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/py-sphinx/package.py>`_.
    If you're using a ``python`` from Spack and you installed
    ``py-sphinx`` and friends, you need to make them available to your
    ``python``. The easiest way to do this is to run:

lib/spack/docs/developer_guide.rst

@@ -154,9 +154,7 @@ Package-related modules
 
 :mod:`spack.util.naming`
   Contains functions for mapping between Spack package names,
-  Python module names, and Python class names. Functions like
-  :func:`~spack.util.naming.mod_to_class` handle mapping package
-  module names to class names.
+  Python module names, and Python class names.
 
 :mod:`spack.directives`
   *Directives* are functions that can be called inside a package definition

lib/spack/docs/environments.rst

@@ -539,7 +539,9 @@ from the command line.
 
 You can also include an environment directly in the ``spack.yaml`` file. It
 involves adding the ``include_concrete`` heading in the yaml followed by the
-absolute path to the independent environments.
+absolute path to the independent environments. Note, that you may use Spack
+config variables such as ``$spack`` or environment variables as long as the
+expression expands to an absolute path.
 
 .. code-block:: yaml
 
@@ -549,7 +551,7 @@ absolute path to the independent environments.
          unify: true
      include_concrete:
      - /absolute/path/to/environment1
-     - /absolute/path/to/environment2
+     - $spack/../path/to/environment2
 
 
 Once the ``spack.yaml`` has been updated you must concretize the environment to

lib/spack/docs/features.rst

@@ -131,7 +131,7 @@ creates a simple python file:
 It doesn't take much python coding to get from there to a working
 package:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/libelf/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/libelf/package.py
    :lines: 5-
 
 Spack also provides wrapper functions around common commands like

lib/spack/docs/getting_started.rst

@@ -20,7 +20,7 @@ be present on the machine where Spack is run:
    :header-rows: 1
 
 These requirements can be easily installed on most modern Linux systems;
-on macOS, the Command Line Tools package is required, and a full XCode suite
+on macOS, the Command Line Tools package is required, and a full Xcode suite
 may be necessary for some packages such as Qt and apple-gl. Spack is designed
 to run on HPC platforms like Cray.  Not all packages should be expected
 to work on all platforms.

lib/spack/docs/index.rst

@@ -103,6 +103,7 @@ or refer to the full manual below.
    :caption: API Docs
 
    Spack API Docs <spack>
+   Spack Builtin Repo <spack_repo>
    LLNL API Docs <llnl>
 
 ==================

lib/spack/docs/module_file_support.rst

@@ -8,7 +8,7 @@
 Modules (modules.yaml)
 ======================
 
-The use of module systems to manage user environment in a controlled way
+The use of module systems to manage user environments in a controlled way
 is a common practice at HPC centers that is sometimes embraced also by
 individual programmers on their development machines. To support this
 common practice Spack integrates with `Environment Modules
@@ -490,7 +490,7 @@ that are already in the Lmod hierarchy.
 
 
 .. note::
-   Tcl and Lua modules also allow for explicit conflicts between modulefiles.
+   Tcl and Lua modules also allow for explicit conflicts between module files.
 
    .. code-block:: yaml
 
@@ -513,7 +513,7 @@ that are already in the Lmod hierarchy.
    :meth:`~spack.spec.Spec.format` method.
 
    For Lmod and Environment Modules versions prior 4.2, it is important to
-   express the conflict on both modulefiles conflicting with each other.
+   express the conflict on both module files conflicting with each other.
 
 
 .. note::
@@ -550,7 +550,7 @@ that are already in the Lmod hierarchy.
 
 .. warning::
   Consistency of Core packages
-   The user is responsible for maintining consistency among core packages, as ``core_specs``
+   The user is responsible for maintaining consistency among core packages, as ``core_specs``
    bypasses the hierarchy that allows Lmod to safely switch between coherent software stacks.
 
 .. warning::

lib/spack/docs/packaging_guide.rst

@@ -69,7 +69,7 @@ An example for ``CMake`` is, for instance:
 
 The predefined steps for each build system are called "phases".
 In general, the name and order in which the phases will be executed can be
-obtained by either reading the API docs at :py:mod:`~.spack.build_systems`, or
+obtained by either reading the API docs at :py:mod:`~.spack_repo.builtin.build_systems`, or
 using the ``spack info`` command:
 
 .. code-block:: console
@@ -158,7 +158,7 @@ builder class explicitly. Using the same example as above, this reads:
            url_fmt = "https://github.com/uclouvain/openjpeg/archive/version.{0}.tar.gz"
            return url_fmt.format(version)
 
-   class CMakeBuilder(spack.build_systems.cmake.CMakeBuilder):
+   class CMakeBuilder(spack_repo.builtin.build_systems.cmake.CMakeBuilder):
        def cmake_args(self):
            args = [
                self.define_from_variant("BUILD_CODEC", "codec"),
@@ -179,7 +179,7 @@ Spack can be found at :ref:`package_class_structure`.
 
    .. code-block:: python
 
-      class Foo(CmakePackage):
+      class Foo(CMakePackage):
           def cmake_args(self):
               ...
 
@@ -256,7 +256,7 @@ for details):
    #
    # See the Spack documentation for more information on packaging.
    # ----------------------------------------------------------------------------
-   import spack.build_systems.autotools
+   import spack_repo.builtin.build_systems.autotools
    from spack.package import *
 
 
@@ -369,9 +369,9 @@ If you have a collection of software expected to work well together with
 no source code of its own, you can create a :ref:`BundlePackage <bundlepackage>`.
 Examples where bundle packages can be useful include defining suites of
 applications (e.g, `EcpProxyApps
-<https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/ecp-proxy-apps/package.py>`_), commonly used libraries
-(e.g., `AmdAocl <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/amd-aocl/package.py>`_),
-and software development kits (e.g., `EcpDataVisSdk <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/ecp-data-vis-sdk/package.py>`_).
+<https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/ecp_proxy_apps/package.py>`_), commonly used libraries
+(e.g., `AmdAocl <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/amd_aocl/package.py>`_),
+and software development kits (e.g., `EcpDataVisSdk <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/ecp_data_vis_sdk/package.py>`_).
 
 These versioned packages primarily consist of dependencies on the associated
 software packages. They can include :ref:`variants <variants>` to ensure
@@ -443,7 +443,7 @@ lives in:
 .. code-block:: console
 
    $ spack location -p gmp
-   ${SPACK_ROOT}/var/spack/repos/builtin/packages/gmp/package.py
+   ${SPACK_ROOT}/var/spack/repos/spack_repo/builtin/packages/gmp/package.py
 
 but ``spack edit`` provides a much simpler shortcut and saves you the
 trouble of typing the full path.
@@ -457,19 +457,19 @@ live in Spack's directory structure.  In general, :ref:`cmd-spack-create`
 handles creating package files for you, so you can skip most of the
 details here.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-``var/spack/repos/builtin/packages``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+``var/spack/repos/spack_repo/builtin/packages``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A Spack installation directory is structured like a standard UNIX
 install prefix (``bin``, ``lib``, ``include``, ``var``, ``opt``,
 etc.).  Most of the code for Spack lives in ``$SPACK_ROOT/lib/spack``.
-Packages themselves live in ``$SPACK_ROOT/var/spack/repos/builtin/packages``.
+Packages themselves live in ``$SPACK_ROOT/var/spack/repos/spack_repo/builtin/packages``.
 
 If you ``cd`` to that directory, you will see directories for each
 package:
 
-.. command-output:: cd $SPACK_ROOT/var/spack/repos/builtin/packages && ls
+.. command-output:: cd $SPACK_ROOT/var/spack/repos/spack_repo/builtin/packages && ls
    :shell:
    :ellipsis: 10
 
@@ -479,7 +479,7 @@ package lives in:
 
 .. code-block:: none
 
-   $SPACK_ROOT/var/spack/repos/builtin/packages/libelf/package.py
+   $SPACK_ROOT/var/spack/repos/spack_repo/builtin/packages/libelf/package.py
 
 Alongside the ``package.py`` file, a package may contain extra
 directories or files (like patches) that it needs to build.
@@ -492,12 +492,12 @@ Packages are named after the directory containing ``package.py``. So,
 ``libelf``'s ``package.py`` lives in a directory called ``libelf``.
 The ``package.py`` file defines a class called ``Libelf``, which
 extends Spack's ``Package`` class.  For example, here is
-``$SPACK_ROOT/var/spack/repos/builtin/packages/libelf/package.py``:
+``$SPACK_ROOT/var/spack/repos/spack_repo/builtin/packages/libelf/package.py``:
 
 .. code-block:: python
    :linenos:
 
-   from spack import *
+   from spack.package import *
 
    class Libelf(Package):
        """ ... description ... """
@@ -520,7 +520,7 @@ these:
    $ spack install libelf@0.8.13
 
 Spack sees the package name in the spec and looks for
-``libelf/package.py`` in ``var/spack/repos/builtin/packages``.
+``libelf/package.py`` in ``var/spack/repos/spack_repo/builtin/packages``.
 Likewise, if you run ``spack install py-numpy``, Spack looks for
 ``py-numpy/package.py``.
 
@@ -686,7 +686,7 @@ https://www.open-mpi.org/software/ompi/v2.1/downloads/openmpi-2.1.1.tar.bz2
 In order to handle this, you can define a ``url_for_version()`` function
 like so:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/openmpi/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/openmpi/package.py
    :pyobject: Openmpi.url_for_version
 
 With the use of this ``url_for_version()``, Spack knows to download OpenMPI ``2.1.1``
@@ -787,7 +787,7 @@ of GNU. For that, Spack goes a step further and defines a mixin class that
 takes care of all of the plumbing and requires packagers to just define a proper
 ``gnu_mirror_path`` attribute:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/autoconf/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/autoconf/package.py
    :lines: 9-18
 
 ^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1089,7 +1089,7 @@ You've already seen the ``homepage`` and ``url`` package attributes:
 .. code-block:: python
    :linenos:
 
-   from spack import *
+   from spack.package import *
 
 
    class Mpich(Package):
@@ -1212,7 +1212,7 @@ class-level tarball URL and VCS. For example:
        version("master",  branch="master")
        version("12.12.1", md5="ecd4606fa332212433c98bf950a69cc7")
        version("12.10.1", md5="667333dbd7c0f031d47d7c5511fd0810")
-       version("12.8.1",  "9f37f683ee2b427b5540db8a20ed6b15")
+       version("12.8.1",  md5="9f37f683ee2b427b5540db8a20ed6b15")
 
 If a package contains both a ``url`` and ``git`` class-level attribute,
 Spack decides which to use based on the arguments to the ``version()``
@@ -1343,7 +1343,7 @@ Submodules
 
      version("1.0.1", tag="v1.0.1", submodules=True)
 
-  If a package has needs more fine-grained control over submodules, define
+  If a package needs more fine-grained control over submodules, define
   ``submodules`` to be a callable function that takes the package instance as
   its only argument.  The function should return a list of submodules to be fetched.
 
@@ -1995,7 +1995,7 @@ structure like this:
 
 .. code-block:: none
 
-   $SPACK_ROOT/var/spack/repos/builtin/packages/
+   $SPACK_ROOT/var/spack/repos/spack_repo/builtin/packages/
        mvapich2/
            package.py
            ad_lustre_rwcontig_open_source.patch
@@ -2133,7 +2133,7 @@ handles ``RPATH``:
 
 .. _pyside-patch:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/py-pyside/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/py_pyside/package.py
    :pyobject: PyPyside.patch
    :linenos:
 
@@ -2201,7 +2201,7 @@ using the ``spack resource show`` command::
 
   $ spack resource show 3877ab54
   3877ab548f88597ab2327a2230ee048d2d07ace1062efe81fc92e91b7f39cd00
-      path:       /home/spackuser/src/spack/var/spack/repos/builtin/packages/m4/gnulib-pgi.patch
+      path:       /home/spackuser/src/spack/var/spack/repos/spack_repo/builtin/packages/m4/gnulib-pgi.patch
       applies to: builtin.m4
 
 ``spack resource show`` looks up downloadable resources from package
@@ -2219,7 +2219,7 @@ wonder where the extra boost patches are coming from::
           ^boost@1.68.0%apple-clang@9.0.0+atomic+chrono~clanglibcpp cxxstd=default +date_time~debug+exception+filesystem+graph~icu+iostreams+locale+log+math~mpi+multithreaded~numpy patches=2ab6c72d03dec6a4ae20220a9dfd5c8c572c5294252155b85c6874d97c323199,b37164268f34f7133cbc9a4066ae98fda08adf51e1172223f6a969909216870f ~pic+program_options~python+random+regex+serialization+shared+signals~singlethreaded+system~taggedlayout+test+thread+timer~versionedlayout+wave arch=darwin-highsierra-x86_64
   $ spack resource show b37164268
   b37164268f34f7133cbc9a4066ae98fda08adf51e1172223f6a969909216870f
-      path:       /home/spackuser/src/spack/var/spack/repos/builtin/packages/dealii/boost_1.68.0.patch
+      path:       /home/spackuser/src/spack/var/spack/repos/spack_repo/builtin/packages/dealii/boost_1.68.0.patch
       applies to: builtin.boost
       patched by: builtin.dealii
 
@@ -2253,22 +2253,15 @@ RPATHs in Spack are handled in one of three ways:
    set in standard variables like ``CC``, ``CXX``, ``F77``, and ``FC``,
    so most build systems (autotools and many gmake systems) pick them
    up and use them.
-#. CMake also respects Spack's compiler wrappers, but many CMake
-   builds have logic to overwrite RPATHs when binaries are
-   installed. Spack provides the ``std_cmake_args`` variable, which
-   includes parameters necessary for CMake build use the right
-   installation RPATH.  It can be used like this when ``cmake`` is
-   invoked:
-
-   .. code-block:: python
-
-      class MyPackage(Package):
-          ...
-          def install(self, spec, prefix):
-              cmake("..", *std_cmake_args)
-              make()
-              make("install")
-
+#. CMake has its own RPATH handling, and distinguishes between build and
+   install RPATHs. By default, during the build it registers RPATHs to
+   all libraries it links to, so that just-built executables can be run
+   during the build itself. Upon installation, these RPATHs are cleared,
+   unless the user defines the install RPATHs. When inheriting from
+   ``CMakePackage``, Spack handles this automatically, and sets
+   ``CMAKE_INSTALL_RPATH_USE_LINK_PATH`` and ``CMAKE_INSTALL_RPATH``,
+   so that libraries of dependencies and the package's own libraries
+   can be found at runtime.
 #. If you need to modify the build to add your own RPATHs, you can
    use the ``self.rpath`` property of your package, which will
    return a list of all the RPATHs that Spack will use when it
@@ -2315,31 +2308,19 @@ looks like this:
 
        parallel = False
 
-Similarly, you can disable parallel builds only for specific make
-commands, as ``libdwarf`` does:
+You can also disable parallel builds only for specific make
+invocation:
 
 .. code-block:: python
-   :emphasize-lines: 9, 12
+   :emphasize-lines: 5
    :linenos:
 
    class Libelf(Package):
        ...
 
        def install(self, spec, prefix):
-           configure("--prefix=" + prefix,
-                     "--enable-shared",
-                     "--disable-dependency-tracking",
-                     "--disable-debug")
-           make()
-
-           # The mkdir commands in libelf's install can fail in parallel
            make("install", parallel=False)
 
-The first make will run in parallel here, but the second will not.  If
-you set ``parallel`` to ``False`` at the package level, then each call
-to ``make()`` will be sequential by default, but packagers can call
-``make(parallel=True)`` to override it.
-
 Note that the ``--jobs`` option works out of the box for all standard
 build systems. If you are using a non-standard build system instead, you
 can use the variable ``make_jobs`` to extract the number of jobs specified
@@ -2514,7 +2495,7 @@ necessary when there are breaking changes in the dependency that the
 package cannot handle. In Spack we often add forward compatibility
 bounds only at the time a new, breaking version of a dependency is
 released. As with backward compatibility, it is typical to see a list
-of forward compatibility bounds in a package file as seperate lines:
+of forward compatibility bounds in a package file as separate lines:
 
 .. code-block:: python
 
@@ -2930,7 +2911,7 @@ this, Spack provides four different methods that can be overridden in a package:
 
 The Qt package, for instance, uses this call:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/qt/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/qt/package.py
    :pyobject: Qt.setup_dependent_build_environment
    :linenos:
 
@@ -2958,7 +2939,7 @@ variables to be used by the dependent. This is done by implementing
 :meth:`setup_dependent_package <spack.package_base.PackageBase.setup_dependent_package>`. An
 example of this can be found in the ``Python`` package:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/python/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/python/package.py
    :pyobject: Python.setup_dependent_package
    :linenos:
 
@@ -3390,7 +3371,7 @@ the above attribute implementations:
        "/opt/spack/linux-fedora35-haswell/gcc-11.3.1/foo-1.0-ca3rczp5omy7dfzoqw4p7oc2yh3u7lt6/baz/lib/libFooBaz.so"
    ])
 
-   # baz library directories in the baz subdirectory of the foo porefix
+   # baz library directories in the baz subdirectory of the foo prefix
    >>> spec["baz"].libs.directories
    [
        "/opt/spack/linux-fedora35-haswell/gcc-11.3.1/foo-1.0-ca3rczp5omy7dfzoqw4p7oc2yh3u7lt6/baz/lib"
@@ -3704,60 +3685,57 @@ the build system. The build systems currently supported by Spack are:
 +----------------------------------------------------------+----------------------------------+
 |     **API docs**                                         |           **Description**        |
 +==========================================================+==================================+
-| :class:`~spack.build_systems.generic`                    | Generic build system without any |
+| :class:`~spack_repo.builtin.build_systems.generic`       | Generic build system without any |
 |                                                          | base implementation              |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.makefile`                   | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.makefile`      | Specialized build system for     |
 |                                                          | software built invoking          |
 |                                                          | hand-written Makefiles           |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.autotools`                  | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.autotools`     | Specialized build system for     |
 |                                                          | software built using             |
 |                                                          | GNU Autotools                    |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.cmake`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.cmake`         | Specialized build system for     |
 |                                                          | software built using CMake       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.maven`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.maven`         | Specialized build system for     |
 |                                                          | software built using Maven       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.meson`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.meson`         | Specialized build system for     |
 |                                                          | software built using Meson       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.nmake`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.nmake`         | Specialized build system for     |
 |                                                          | software built using NMake       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.qmake`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.qmake`         | Specialized build system for     |
 |                                                          | software built using QMake       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.scons`                      | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.scons`         | Specialized build system for     |
 |                                                          | software built using SCons       |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.waf`                        | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.waf`           | Specialized build system for     |
 |                                                          | software built using Waf         |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.r`                          | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.r`             | Specialized build system for     |
 |                                                          | R extensions                     |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.octave`                     | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.octave`        | Specialized build system for     |
 |                                                          | Octave packages                  |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.python`                     | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.python`        | Specialized build system for     |
 |                                                          | Python extensions                |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.perl`                       | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.perl`          | Specialized build system for     |
 |                                                          | Perl extensions                  |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.ruby`                       | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.ruby`          | Specialized build system for     |
 |                                                          | Ruby extensions                  |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.intel`                      | Specialized build system for     |
-|                                                          | licensed Intel software          |
-+----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.oneapi`                     | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.oneapi`        | Specialized build system for     |
 |                                                          | Intel oneAPI software            |
 +----------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.aspell_dict`                | Specialized build system for     |
+| :class:`~spack_repo.builtin.build_systems.aspell_dict`   | Specialized build system for     |
 |                                                          | Aspell dictionaries              |
 +----------------------------------------------------------+----------------------------------+
 
@@ -3769,7 +3747,7 @@ the build system. The build systems currently supported by Spack are:
         rare cases where manual intervention is needed we need to stress that a
         package base class depends on the *build system* being used, not the language of the package.
         For example, a Python extension installed with CMake would ``extends("python")`` and
-        subclass from :class:`~spack.build_systems.cmake.CMakePackage`.
+        subclass from :class:`~spack_repo.builtin.build_systems.cmake.CMakePackage`.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 Overriding builder methods
@@ -3777,7 +3755,7 @@ Overriding builder methods
 
 Build-system "phases" have default implementations that fit most of the common cases:
 
-.. literalinclude:: _spack_root/lib/spack/spack/build_systems/autotools.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/build_systems/autotools.py
     :pyobject: AutotoolsBuilder.configure
     :linenos:
 
@@ -3785,13 +3763,13 @@ It is usually sufficient for a packager to override a few
 build system specific helper methods or attributes to provide, for instance,
 configure arguments:
 
-.. literalinclude::  _spack_root/var/spack/repos/builtin/packages/m4/package.py
+.. literalinclude::  _spack_root/var/spack/repos/spack_repo/builtin/packages/m4/package.py
     :pyobject: M4.configure_args
     :linenos:
 
 Each specific build system has a list of attributes and methods that can be overridden to
 fine-tune the installation of a package without overriding an entire phase. To
-have more information on them the place to go is the API docs of the :py:mod:`~.spack.build_systems`
+have more information on them the place to go is the API docs of the :py:mod:`~.spack_repo.builtin.build_systems`
 module.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -3833,7 +3811,7 @@ If the ``package.py`` has build instructions in a separate
 
 .. code-block:: python
 
-   class CMakeBuilder(spack.build_systems.cmake.CMakeBuilder):
+   class CMakeBuilder(spack_repo.builtin.build_systems.cmake.CMakeBuilder):
        def install(self, pkg, spec, prefix):
            ...
 
@@ -3846,31 +3824,32 @@ Mixin base classes
 Besides build systems, there are other cases where common metadata and behavior can be extracted
 and reused by many packages. For instance, packages that depend on ``Cuda`` or ``Rocm``, share
 common dependencies and constraints. To factor these attributes into a single place, Spack provides
-a few mixin classes in the ``spack.build_systems`` module:
+a few mixin classes in the ``spack_repo.builtin.build_systems`` module:
 
-+---------------------------------------------------------------+----------------------------------+
-|     **API docs**                                              |           **Description**        |
-+===============================================================+==================================+
-| :class:`~spack.build_systems.cuda.CudaPackage`                | A helper class for packages that |
-|                                                               | use CUDA                         |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.rocm.ROCmPackage`                | A helper class for packages that |
-|                                                               | use ROCm                         |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.gnu.GNUMirrorPackage`            | A helper class for GNU packages  |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.python.PythonExtension`          | A helper class for Python        |
-|                                                               | extensions                       |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.sourceforge.SourceforgePackage`  | A helper class for packages      |
-|                                                               | from sourceforge.org             |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.sourceware.SourcewarePackage`    | A helper class for packages      |
-|                                                               | from sourceware.org              |
-+---------------------------------------------------------------+----------------------------------+
-| :class:`~spack.build_systems.xorg.XorgPackage`                | A helper class for x.org         |
-|                                                               | packages                         |
-+---------------------------------------------------------------+----------------------------------+
++----------------------------------------------------------------------------+----------------------------------+
+|     **API docs**                                                           |           **Description**        |
++============================================================================+==================================+
+| :class:`~spack_repo.builtin.build_systems.cuda.CudaPackage`                | A helper class for packages that |
+|                                                                            | use CUDA                         |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.rocm.ROCmPackage`                | A helper class for packages that |
+|                                                                            | use ROCm                         |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.gnu.GNUMirrorPackage`            | A helper class for GNU packages  |
+|                                                                            |                                  |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.python.PythonExtension`          | A helper class for Python        |
+|                                                                            | extensions                       |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.sourceforge.SourceforgePackage`  | A helper class for packages      |
+|                                                                            | from sourceforge.org             |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.sourceware.SourcewarePackage`    | A helper class for packages      |
+|                                                                            | from sourceware.org              |
++----------------------------------------------------------------------------+----------------------------------+
+| :class:`~spack_repo.builtin.build_systems.xorg.XorgPackage`                | A helper class for x.org         |
+|                                                                            | packages                         |
++----------------------------------------------------------------------------+----------------------------------+
 
 These classes should be used by adding them to the inheritance tree of the package that needs them,
 for instance:
@@ -3914,13 +3893,13 @@ Additional build instructions are split into separate builder classes:
 
 .. code-block:: python
 
-   class CMakeBuilder(spack.build_systems.cmake.CMakeBuilder):
+   class CMakeBuilder(spack_repo.builtin.build_systems.cmake.CMakeBuilder):
        def cmake_args(self):
            return [
                self.define_from_variant("MY_FEATURE", "my_feature")
            ]
 
-   class AutotoolsBuilder(spack.build_systems.autotools.AutotoolsBuilder):
+   class AutotoolsBuilder(spack_repo.builtin.build_systems.autotools.AutotoolsBuilder):
        def configure_args(self):
            return self.with_or_without("my-feature", variant="my_feature")
 
@@ -4110,7 +4089,7 @@ Shell command functions
 
 Recall the install method from ``libelf``:
 
-.. literalinclude::  _spack_root/var/spack/repos/builtin/packages/libelf/package.py
+.. literalinclude::  _spack_root/var/spack/repos/spack_repo/builtin/packages/libelf/package.py
    :pyobject: Libelf.install
    :linenos:
 
@@ -4901,7 +4880,7 @@ the one passed to install, only the MPI implementations all set some
 additional properties on it to help you out.  E.g., in openmpi, you'll
 find this:
 
-.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/openmpi/package.py
+.. literalinclude:: _spack_root/var/spack/repos/spack_repo/builtin/packages/openmpi/package.py
    :pyobject: Openmpi.setup_dependent_package
 
 That code allows the ``openmpi`` package to associate an ``mpicc`` property
@@ -5749,7 +5728,7 @@ running each executable, ``foo`` and ``bar``, as independent test parts.
 .. note::
 
    The method name ``copy_test_files`` here is for illustration purposes.
-   You are free to use a name that is more suited to your package.
+   You are free to use a name that is better suited to your package.
 
    The key to copying files for stand-alone testing at build time is use
    of the ``run_after`` directive, which ensures the associated files are
@@ -6001,16 +5980,16 @@ with those implemented in the package itself.
    * - Parent/Provider Package
      - Stand-alone Tests
    * - `C
-       <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/c>`_
+       <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/c>`_
      - Compiles ``hello.c`` and runs it
    * - `Cxx
-       <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/cxx>`_
+       <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/cxx>`_
      - Compiles and runs several ``hello`` programs
    * - `Fortran
-       <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/fortran>`_
+       <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/fortran>`_
      - Compiles and runs ``hello`` programs (``F`` and ``f90``)
    * - `Mpi
-       <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/mpi>`_
+       <https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/mpi>`_
      - Compiles and runs ``mpi_hello`` (``c``, ``fortran``)
    * - :ref:`PythonPackage <pythonpackage>`
      - Imports modules listed in the ``self.import_modules`` property with defaults derived from the tarball
@@ -6031,7 +6010,7 @@ maintainers provide additional stand-alone tests customized to the package.
 One example of a package that adds its own stand-alone tests to those
 "inherited" by the virtual package it provides an implementation for is
 the `Openmpi package
-<https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/openmpi/package.py>`_.
+<https://github.com/spack/spack/blob/develop/var/spack/repos/spack_repo/builtin/packages/openmpi/package.py>`_.
 
 Below are snippets from running and viewing the stand-alone test results
 for ``openmpi``:
@@ -6183,7 +6162,7 @@ running:
 
 .. code-block:: python
 
-   from spack import *
+   from spack.package import *
 
 This is already part of the boilerplate for packages created with
 ``spack create``.
@@ -7258,7 +7237,7 @@ which are not, there is the `checked_by` parameter in the license directive:
 
    license("<license>", when="<when>", checked_by="<github username>")
 
-When you have validated a github license, either when doing so explicitly or
+When you have validated a package license, either when doing so explicitly or
 as part of packaging a new package, please set the `checked_by` parameter
 to your Github username to signal that the license has been manually
 verified.

lib/spack/docs/replace_conda_homebrew.rst

@@ -214,7 +214,7 @@ package versions, simply run the following commands:
 
 Running ``spack mark -i --all`` tells Spack to mark all of the existing
 packages within an environment as "implicitly" installed. This tells
-spack's garbage collection system that these packages should be cleaned up.
+Spack's garbage collection system that these packages should be cleaned up.
 
 Don't worry however, this will not remove your entire environment.
 Running ``spack install`` will reexamine your spack environment after

lib/spack/docs/repositories.rst

@@ -9,7 +9,7 @@ Package Repositories (repos.yaml)
 =================================
 
 Spack comes with thousands of built-in package recipes in
-``var/spack/repos/builtin/``.  This is a **package repository** -- a
+``var/spack/repos/spack_repo/builtin/``.  This is a **package repository** -- a
 directory that Spack searches when it needs to find a package by name.
 You may need to maintain packages for restricted, proprietary or
 experimental software separately from the built-in repository. Spack
@@ -69,7 +69,7 @@ The default ``etc/spack/defaults/repos.yaml`` file looks like this:
 .. code-block:: yaml
 
   repos:
-  - $spack/var/spack/repos/builtin
+  - $spack/var/spack/repos/spack_repo/builtin
 
 The file starts with ``repos:`` and contains a single ordered list of
 paths to repositories. Each path is on a separate line starting with
@@ -78,16 +78,16 @@ paths to repositories. Each path is on a separate line starting with
 .. code-block:: yaml
 
   repos:
-  - /opt/local-repo
-  - $spack/var/spack/repos/builtin
+  - /opt/repos/spack_repo/local_repo
+  - $spack/var/spack/repos/spack_repo/builtin
 
 When Spack interprets a spec, e.g., ``mpich`` in ``spack install mpich``,
 it searches these repositories in order (first to last) to resolve each
 package name.  In this example, Spack will look for the following
 packages and use the first valid file:
 
-1. ``/opt/local-repo/packages/mpich/package.py``
-2. ``$spack/var/spack/repos/builtin/packages/mpich/package.py``
+1. ``/opt/repos/spack_repo/local_repo/packages/mpich/package.py``
+2. ``$spack/var/spack/repos/spack_repo/builtin/packages/mpich/package.py``
 
 .. note::
 
@@ -101,14 +101,15 @@ Namespaces
 
 Every repository in Spack has an associated **namespace** defined in its
 top-level ``repo.yaml`` file.  If you look at
-``var/spack/repos/builtin/repo.yaml`` in the built-in repository, you'll
+``var/spack/repos/spack_repo/builtin/repo.yaml`` in the built-in repository, you'll
 see that its namespace is ``builtin``:
 
 .. code-block:: console
 
-  $ cat var/spack/repos/builtin/repo.yaml
+  $ cat var/spack/repos/spack_repo/builtin/repo.yaml
   repo:
     namespace: builtin
+    api: v2.0
 
 Spack records the repository namespace of each installed package.  For
 example, if you install the ``mpich`` package from the ``builtin`` repo,
@@ -217,15 +218,15 @@ Suppose you have three repositories: the builtin Spack repo
 repo containing your own prototype packages (``proto``).  Suppose they
 contain packages as follows:
 
-  +--------------+------------------------------------+-----------------------------+
-  | Namespace    | Path to repo                       | Packages                    |
-  +==============+====================================+=============================+
-  | ``proto``    | ``~/proto``                        | ``mpich``                   |
-  +--------------+------------------------------------+-----------------------------+
-  | ``llnl``     | ``/usr/local/llnl``                | ``hdf5``                    |
-  +--------------+------------------------------------+-----------------------------+
-  | ``builtin``  | ``$spack/var/spack/repos/builtin`` | ``mpich``, ``hdf5``, others |
-  +--------------+------------------------------------+-----------------------------+
+  +--------------+-----------------------------------------------+-----------------------------+
+  | Namespace    | Path to repo                                  | Packages                    |
+  +==============+===============================================+=============================+
+  | ``proto``    | ``~/my_spack_repos/spack_repo/proto``         | ``mpich``                   |
+  +--------------+-----------------------------------------------+-----------------------------+
+  | ``llnl``     | ``/usr/local/repos/spack_repo/llnl``          | ``hdf5``                    |
+  +--------------+-----------------------------------------------+-----------------------------+
+  | ``builtin``  | ``$spack/var/spack/repos/spack_repo/builtin`` | ``mpich``, ``hdf5``, others |
+  +--------------+-----------------------------------------------+-----------------------------+
 
 Suppose that ``hdf5`` depends on ``mpich``.  You can override the
 built-in ``hdf5`` by adding the ``llnl`` repo to ``repos.yaml``:
@@ -233,8 +234,8 @@ built-in ``hdf5`` by adding the ``llnl`` repo to ``repos.yaml``:
 .. code-block:: yaml
 
    repos:
-   - /usr/local/llnl
-   - $spack/var/spack/repos/builtin
+   - /usr/local/repos/spack_repo/llnl
+   - $spack/var/spack/repos/spack_repo/builtin
 
 ``spack install hdf5`` will install ``llnl.hdf5 ^builtin.mpich``.
 
@@ -243,9 +244,9 @@ If, instead, ``repos.yaml`` looks like this:
 .. code-block:: yaml
 
    repos:
-   - ~/proto
-   - /usr/local/llnl
-   - $spack/var/spack/repos/builtin
+   - ~/my_spack_repos/spack_repo/proto
+   - /usr/local/repos/spack_repo/llnl
+   - $spack/var/spack/repos/spack_repo/builtin
 
 ``spack install hdf5`` will install ``llnl.hdf5 ^proto.mpich``.
 
@@ -326,8 +327,8 @@ files, use ``spack repo list``.
 
   $ spack repo list
   ==> 2 package repositories.
-  myrepo     ~/myrepo
-  builtin    ~/spack/var/spack/repos/builtin
+  myrepo     v2.0    ~/my_spack_repos/spack_repo/myrepo
+  builtin    v2.0    ~/spack/var/spack/repos/spack_repo/builtin
 
 Each repository is listed with its associated namespace.  To get the raw,
 merged YAML from all configuration files, use ``spack config get repos``:
@@ -335,9 +336,9 @@ merged YAML from all configuration files, use ``spack config get repos``:
 .. code-block:: console
 
    $ spack config get repos
-   repos:srepos:
-   - ~/myrepo
-   - $spack/var/spack/repos/builtin
+   repos:
+   - ~/my_spack_repos/spack_repo/myrepo
+   - $spack/var/spack/repos/spack_repo/builtin
 
 Note that, unlike ``spack repo list``, this does not include the
 namespace, which is read from each repo's ``repo.yaml``.
@@ -351,66 +352,54 @@ yourself; you can use the ``spack repo create`` command.
 
 .. code-block:: console
 
-  $ spack repo create myrepo
+  $ spack repo create ~/my_spack_repos myrepo
   ==> Created repo with namespace 'myrepo'.
   ==> To register it with spack, run this command:
-    spack repo add ~/myrepo
+    spack repo add ~/my_spack_repos/spack_repo/myrepo
 
-  $ ls myrepo
+  $ ls ~/my_spack_repos/spack_repo/myrepo
   packages/  repo.yaml
 
-  $ cat myrepo/repo.yaml
+  $ cat ~/my_spack_repos/spack_repo/myrepo/repo.yaml
   repo:
     namespace: 'myrepo'
+    api: v2.0
 
-By default, the namespace of a new repo matches its directory's name.
-You can supply a custom namespace with a second argument, e.g.:
+Namespaces can also be nested, which can be useful if you have
+multiple package repositories for an organization. Spack will
+create the corresponding directory structure for you:
 
 .. code-block:: console
 
-  $ spack repo create myrepo llnl.comp
+  $ spack repo create ~/my_spack_repos llnl.comp
   ==> Created repo with namespace 'llnl.comp'.
   ==> To register it with spack, run this command:
-    spack repo add ~/myrepo
+    spack repo add ~/my_spack_repos/spack_repo/llnl/comp
 
-  $ cat myrepo/repo.yaml
+
+  $ cat ~/my_spack_repos/spack_repo/llnl/comp/repo.yaml
   repo:
     namespace: 'llnl.comp'
-
-You can also create repositories with custom structure with the ``-d/--subdirectory``
-argument, e.g.:
-
-.. code-block:: console
-
-  $ spack repo create -d applications myrepo apps
-  ==> Created repo with namespace 'apps'.
-  ==> To register it with Spack, run this command:
-    spack repo add ~/myrepo
-
-  $ ls myrepo
-  applications/  repo.yaml
-
-  $ cat myrepo/repo.yaml
-  repo:
-    namespace: apps
-    subdirectory: applications
+    api: v2.0
 
 ^^^^^^^^^^^^^^^^^^
 ``spack repo add``
 ^^^^^^^^^^^^^^^^^^
 
 Once your repository is created, you can register it with Spack with
-``spack repo add``:
+``spack repo add``. You nee to specify the path to the directory that
+contains the ``repo.yaml`` file.
 
 .. code-block:: console
 
-   $ spack repo add ./myrepo
+   $ spack repo add ~/my_spack_repos/spack_repo/llnl/comp
    ==> Added repo with namespace 'llnl.comp'.
 
    $ spack repo list
    ==> 2 package repositories.
-   llnl.comp    ~/myrepo
-   builtin      ~/spack/var/spack/repos/builtin
+  llnl.comp    v2.0    ~/my_spack_repos/spack_repo/llnl/comp
+  builtin      v2.0    ~/spack/var/spack/repos/spack_repo/builtin
+
 
 This simply adds the repo to your ``repos.yaml`` file.
 
@@ -432,46 +421,43 @@ By namespace:
 .. code-block:: console
 
   $ spack repo rm llnl.comp
-  ==> Removed repository ~/myrepo with namespace 'llnl.comp'.
+  ==> Removed repository ~/my_spack_repos/spack_repo/llnl/comp with namespace 'llnl.comp'.
 
   $ spack repo list
   ==> 1 package repository.
-  builtin    ~/spack/var/spack/repos/builtin
+  builtin    ~/spack/var/spack/repos/spack_repo/builtin
 
 By path:
 
 .. code-block:: console
 
-  $ spack repo rm ~/myrepo
-  ==> Removed repository ~/myrepo
+  $ spack repo rm ~/my_spack_repos/spack_repo/llnl/comp
+  ==> Removed repository ~/my_spack_repos/spack_repo/llnl/comp
 
   $ spack repo list
   ==> 1 package repository.
-  builtin    ~/spack/var/spack/repos/builtin
+  builtin    ~/spack/var/spack/repos/spack_repo/builtin
 
 --------------------------------
 Repo namespaces and Python
 --------------------------------
 
-You may have noticed that namespace notation for repositories is similar
-to the notation for namespaces in Python.  As it turns out, you *can*
-treat Spack repositories like Python packages; this is how they are
-implemented.
+Package repositories are implemented as Python packages. To be precise,
+they are `namespace packages
+<https://packaging.python.org/en/latest/guides/packaging-namespace-packages/>`_
+with ``spack_repo`` the top-level namespace, followed by the repository
+namespace as submodules. For example, the builtin repository corresponds
+to the Python module ``spack_repo.builtin.packages``.
 
-You could, for example, extend a ``builtin`` package in your own
+This structure allows you to extend a ``builtin`` package in your own
 repository:
 
 .. code-block:: python
 
-   from spack.pkg.builtin.mpich import Mpich
+   from spack_repo.builtin.packages.mpich.package import Mpich
 
    class MyPackage(Mpich):
        ...
 
-Spack repo namespaces are actually Python namespaces tacked on under
-``spack.pkg``.  The search semantics of ``repos.yaml`` are actually
-implemented using Python's built-in `sys.path
-<https://docs.python.org/2/library/sys.html#sys.path>`_ search.  The
-:py:mod:`spack.repo` module implements a custom `Python importer
-<https://docs.python.org/2/library/imp.html>`_.
-
+Spack populates ``sys.path`` at runtime with the path to the root of your
+package repository's ``spack_repo`` directory.

lib/spack/docs/signing.rst

@@ -176,92 +176,72 @@ community without needing deep familiarity with GnuPG or Public Key
 Infrastructure.
 
 
-.. _build_cache_format:
+.. _build_cache_signing:
 
-------------------
-Build Cache Format
-------------------
+-------------------
+Build Cache Signing
+-------------------
 
-A binary package consists of a metadata file unambiguously defining the
-built package (and including other details such as how to relocate it)
-and the installation directory of the package stored as a compressed
-archive file. The metadata files can either be unsigned, in which case
-the contents are simply the json-serialized concrete spec plus metadata,
-or they can be signed, in which case the json-serialized concrete spec
-plus metadata is wrapped in a gpg cleartext signature. Built package
-metadata files are named to indicate the operating system and
-architecture for which the package was built as well as the compiler
-used to build it and the packages name and version. For example::
+For an in-depth description of the layout of a binary mirror, see
+the :ref:`documentation<build_cache_layout>` covering binary caches. The
+key takeaway from that discussion that applies here is that the entry point
+to a binary package is it's manifest.  The manifest refers unambiguously to the
+spec metadata and compressed archive, which are stored as content-addressed
+blobs.
 
-  linux-ubuntu18.04-haswell-gcc-7.5.0-zlib-1.2.12-llv2ysfdxnppzjrt5ldybb5c52qbmoow.spec.json.sig
-
-would contain the concrete spec and binary metadata for a binary package
-of ``zlib@1.2.12``, built for the ``ubuntu`` operating system and ``haswell``
-architecture. The id of the built package exists in the name of the file
-as well (after the package name and version) and in this case begins
-with ``llv2ys``. The id distinguishes a particular built package from all
-other built packages with the same os/arch, compiler, name, and version.
-Below is an example of a signed binary package metadata file. Such a
-file would live in the ``build_cache`` directory of a binary mirror::
+The manifest files can either be signed or unsigned, but are always given
+a name ending with ``.spec.manifest.json`` regardless. The difference between
+signed and unsigned manifests is simply that the signed version is wrapped in
+a gpg cleartext signature, as illustrated below::
 
   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA512
 
   {
-    "spec": {
-      <concrete-spec-contents-omitted>
-    },
-
-    "buildcache_layout_version": 1,
-    "binary_cache_checksum": {
-      "hash_algorithm": "sha256",
-      "hash": "4f1e46452c35a5e61bcacca205bae1bfcd60a83a399af201a29c95b7cc3e1423"
-     }
+    "version": 3,
+    "data": [
+      {
+        "contentLength": 10731083,
+        "mediaType": "application/vnd.spack.install.v2.tar+gzip",
+        "compression": "gzip",
+        "checksumAlgorithm": "sha256",
+        "checksum": "0f24aa6b5dd7150067349865217acd3f6a383083f9eca111d2d2fed726c88210"
+      },
+      {
+        "contentLength": 1000,
+        "mediaType": "application/vnd.spack.spec.v5+json",
+        "compression": "gzip",
+        "checksumAlgorithm": "sha256",
+        "checksum": "fba751c4796536737c9acbb718dad7429be1fa485f5585d450ab8b25d12ae041"
+      }
+    ]
   }
-
   -----BEGIN PGP SIGNATURE-----
-  iQGzBAEBCgAdFiEETZn0sLle8jIrdAPLx/P+voVcifMFAmKAGvwACgkQx/P+voVc
-  ifNoVgv/VrhA+wurVs5GB9PhmMA1m5U/AfXZb4BElDRwpT8ZcTPIv5X8xtv60eyn
-  4EOneGVbZoMThVxgev/NKARorGmhFXRqhWf+jknJZ1dicpqn/qpv34rELKUpgXU+
-  QDQ4d1P64AIdTczXe2GI9ZvhOo6+bPvK7LIsTkBbtWmopkomVxF0LcMuxAVIbA6b
-  887yBvVO0VGlqRnkDW7nXx49r3AG2+wDcoU1f8ep8QtjOcMNaPTPJ0UnjD0VQGW6
-  4ZFaGZWzdo45MY6tF3o5mqM7zJkVobpoW3iUz6J5tjz7H/nMlGgMkUwY9Kxp2PVH
-  qoj6Zip3LWplnl2OZyAY+vflPFdFh12Xpk4FG7Sxm/ux0r+l8tCAPvtw+G38a5P7
-  QEk2JBr8qMGKASmnRlJUkm1vwz0a95IF3S9YDfTAA2vz6HH3PtsNLFhtorfx8eBi
-  Wn5aPJAGEPOawEOvXGGbsH4cDEKPeN0n6cy1k92uPEmBLDVsdnur8q42jk5c2Qyx
-  j3DXty57
-  =3gvm
+
+  iQGzBAEBCgAdFiEEdbwFKBFJCcB24mB0GAEP+tc8mwcFAmf2rr4ACgkQGAEP+tc8
+  mwfefwv+KJs8MsQ5ovFaBdmyx5H/3k4rO4QHBzuSPOB6UaxErA9IyOB31iP6vNTU
+  HzYpxz6F5dJCJWmmNEMN/0+vjhMHEOkqd7M1l5reVcxduTF2yc4tBZUO2gienEHL
+  W0e+SnUznl1yc/aVpChUiahO2zToCsI8HZRNT4tu6iCnE/OpghqjsSdBOZHmSNDD
+  5wuuCxfDUyWI6ZlLclaaB7RdbCUUJf/iqi711J+wubvnDFhc6Ynwm1xai5laJ1bD
+  ev3NrSb2AAroeNFVo4iECA0fZC1OZQYzaRmAEhBXtCideGJ5Zf2Cp9hmCwNK8Hq6
+  bNt94JP9LqC3FCCJJOMsPyOOhMSA5MU44zyyzloRwEQpHHLuFzVdbTHA3dmTc18n
+  HxNLkZoEMYRc8zNr40g0yb2lCbc+P11TtL1E+5NlE34MX15mPewRCiIFTMwhCnE3
+  gFSKtW1MKustZE35/RUwd2mpJRf+mSRVCl1f1RiFjktLjz7vWQq7imIUSam0fPDr
+  XD4aDogm
+  =RrFX
   -----END PGP SIGNATURE-----
 
 If a user has trusted the public key associated with the private key
-used to sign the above spec file, the signature can be verified with
+used to sign the above manifest file, the signature can be verified with
 gpg, as follows::
 
-  $ gpg –verify linux-ubuntu18.04-haswell-gcc-7.5.0-zlib-1.2.12-llv2ysfdxnppzjrt5ldybb5c52qbmoow.spec.json.sig
+  $ gpg --verify gcc-runtime-12.3.0-s2nqujezsce4x6uhtvxscu7jhewqzztx.spec.manifest.json
 
-The metadata (regardless whether signed or unsigned) contains the checksum
-of the ``.spack`` file containing the actual installation. The checksum should
-be compared to a checksum computed locally on the ``.spack`` file to ensure the
-contents have not changed since the binary spec plus metadata were signed. The
-``.spack`` files are actually tarballs containing the compressed archive of the
-install tree.  These files, along with the metadata files, live within the
-``build_cache`` directory of the mirror, and together are organized as follows::
-
-  build_cache/
-    # unsigned metadata (for indexing, contains sha256 of .spack file)
-    <arch>-<compiler>-<name>-<ver>-24zvipcqgg2wyjpvdq2ajy5jnm564hen.spec.json
-    # clearsigned metadata (same as above, but signed)
-    <arch>-<compiler>-<name>-<ver>-24zvipcqgg2wyjpvdq2ajy5jnm564hen.spec.json.sig
-    <arch>/
-      <compiler>/
-        <name>-<ver>/
-          # tar.gz-compressed prefix (may support more compression formats later)
-          <arch>-<compiler>-<name>-<ver>-24zvipcqgg2wyjpvdq2ajy5jnm564hen.spack
-
-Uncompressing and extracting the ``.spack`` file results in the install tree.
-This is in contrast to previous versions of spack, where the ``.spack`` file
-contained a (duplicated) metadata file, a signature file and a nested tarball
-containing the install tree.
+When attempting to install a binary package that has been signed, spack will
+attempt to verify the signature with one of the trusted keys in its keyring,
+and will fail if unable to do so.  While not recommended, it is possible to
+force installation of a signed package without verification by providing the
+``--no-check-signature`` argument to ``spack install ...``.
 
 .. _internal_implementation:
 
@@ -320,10 +300,10 @@ the following way:
    Reputational Public Key are imported into a keyring by the ``spack gpg …``
    sub-command. This is initiated by the job’s build script which is created by
    the generate job at the beginning of the pipeline.
-4. Assuming the package has dependencies those specs are verified using
+4. Assuming the package has dependencies those spec manifests are verified using
    the keyring.
-5. The package is built and the spec.json is generated
-6. The spec.json is signed by the keyring and uploaded to the mirror’s
+5. The package is built and the spec manifest is generated
+6. The spec manifest is signed by the keyring and uploaded to the mirror’s
    build cache.
 
 **Reputational Key**
@@ -376,24 +356,24 @@ following way:
 4.  In addition to the secret, the runner creates a tmpfs memory mounted
     directory where the GnuPG keyring will be created to verify, and
     then resign the package specs.
-5.  The job script syncs all spec.json.sig files from the build cache to
+5.  The job script syncs all spec manifest files from the build cache to
     a working directory in the job’s execution environment.
 6.  The job script then runs the ``sign.sh`` script built into the
     notary Docker image.
 7.  The ``sign.sh`` script imports the public components of the
     Reputational and Intermediate CI Keys and uses them to verify good
-    signatures on the spec.json.sig files. If any signed spec does not
-    verify the job immediately fails.
-8.  Assuming all specs are verified, the ``sign.sh`` script then unpacks
-    the spec json data from the signed file in preparation for being
+    signatures on the spec.manifest.json files. If any signed manifest
+    does not verify, the job immediately fails.
+8.  Assuming all manifests are verified, the ``sign.sh`` script then unpacks
+    the manifest json data from the signed file in preparation for being
     re-signed with the Reputational Key.
 9.  The private components of the Reputational Key are decrypted to
     standard out using ``aws-encryption-cli`` directly into a ``gpg
     –import …`` statement which imports the key into the
     keyring mounted in-memory.
-10. The private key is then used to sign each of the json specs and the
+10. The private key is then used to sign each of the manifests and the
     keyring is removed from disk.
-11. The re-signed json specs are resynced to the AWS S3 Mirror and the
+11. The re-signed manifests are resynced to the AWS S3 Mirror and the
     public signing of the packages for the develop or release pipeline
     that created them is complete.
 

lib/spack/external/_vendoring/_pyrsistent_version.pyi

@@ -1 +0,0 @@
-from _pyrsistent_version import *

lib/spack/external/_vendoring/altgraph.pyi

@@ -1 +0,0 @@
-from altgraph import *

lib/spack/external/_vendoring/altgraph/Dot.py

@@ -1,8 +1,8 @@
 """
-altgraph.Dot - Interface to the dot language
+_vendoring.altgraph.Dot - Interface to the dot language
 ============================================
 
-The :py:mod:`~altgraph.Dot` module provides a simple interface to the
+The :py:mod:`~_vendoring.altgraph.Dot` module provides a simple interface to the
 file format used in the
 `graphviz <http://www.research.att.com/sw/tools/graphviz/>`_
 program. The module is intended to offload the most tedious part of the process
@@ -20,7 +20,7 @@
 
 Here is a typical usage::
 
-    from altgraph import Graph, Dot
+    from _vendoring.altgraph import Graph, Dot
 
     # create a graph
     edges = [ (1,2), (1,3), (3,4), (3,5), (4,5), (5,4) ]
@@ -77,7 +77,7 @@
 
 .. note::
 
-   dotty (invoked via :py:func:`~altgraph.Dot.display`) may not be able to
+   dotty (invoked via :py:func:`~_vendoring.altgraph.Dot.display`) may not be able to
    display all graphics styles. To verify the output save it to an image file
    and look at it that way.
 
@@ -111,7 +111,7 @@
 import os
 import warnings
 
-from altgraph import GraphError
+from _vendoring.altgraph import GraphError
 
 
 class Dot(object):

lib/spack/external/_vendoring/altgraph/Graph.py

@@ -1,5 +1,5 @@
 """
-altgraph.Graph - Base Graph class
+_vendoring.altgraph.Graph - Base Graph class
 =================================
 
 ..
@@ -15,7 +15,7 @@
 
 from collections import deque
 
-from altgraph import GraphError
+from _vendoring.altgraph import GraphError
 
 
 class Graph(object):

lib/spack/external/_vendoring/altgraph/GraphAlgo.py

@@ -1,8 +1,8 @@
 """
-altgraph.GraphAlgo - Graph algorithms
+_vendoring.altgraph.GraphAlgo - Graph algorithms
 =====================================
 """
-from altgraph import GraphError
+from _vendoring.altgraph import GraphError
 
 
 def dijkstra(graph, start, end=None):
@@ -25,7 +25,7 @@ def dijkstra(graph, start, end=None):
     and will raise an exception if it discovers that a negative edge has
     caused it to make a mistake.
 
-    Adapted to altgraph by Istvan Albert, Pennsylvania State University -
+    Adapted to _vendoring.altgraph by Istvan Albert, Pennsylvania State University -
     June, 9 2004
     """
     D = {}  # dictionary of final distances

lib/spack/external/_vendoring/altgraph/GraphStat.py

@@ -1,5 +1,5 @@
 """
-altgraph.GraphStat - Functions providing various graph statistics
+_vendoring.altgraph.GraphStat - Functions providing various graph statistics
 =================================================================
 """
 

lib/spack/external/_vendoring/altgraph/GraphUtil.py

@@ -1,17 +1,17 @@
 """
-altgraph.GraphUtil - Utility classes and functions
+_vendoring.altgraph.GraphUtil - Utility classes and functions
 ==================================================
 """
 
 import random
 from collections import deque
 
-from altgraph import Graph, GraphError
+from _vendoring.altgraph import Graph, GraphError
 
 
 def generate_random_graph(node_num, edge_num, self_loops=False, multi_edges=False):
     """
-    Generates and returns a :py:class:`~altgraph.Graph.Graph` instance with
+    Generates and returns a :py:class:`~_vendoring.altgraph.Graph.Graph` instance with
     *node_num* nodes randomly connected by *edge_num* edges.
     """
     g = Graph.Graph()
@@ -52,7 +52,7 @@ def generate_random_graph(node_num, edge_num, self_loops=False, multi_edges=Fals
 
 def generate_scale_free_graph(steps, growth_num, self_loops=False, multi_edges=False):
     """
-    Generates and returns a :py:class:`~altgraph.Graph.Graph` instance that
+    Generates and returns a :py:class:`~_vendoring.altgraph.Graph.Graph` instance that
     will have *steps* \\* *growth_num* nodes and a scale free (powerlaw)
     connectivity. Starting with a fully connected graph with *growth_num*
     nodes at every step *growth_num* nodes are added to the graph and are

lib/spack/external/_vendoring/altgraph/ObjectGraph.py

@@ -1,14 +1,14 @@
 """
-altgraph.ObjectGraph - Graph of objects with an identifier
+_vendoring.altgraph.ObjectGraph - Graph of objects with an identifier
 ==========================================================
 
 A graph of objects that have a "graphident" attribute.
 graphident is the key for the object in the graph
 """
 
-from altgraph import GraphError
-from altgraph.Graph import Graph
-from altgraph.GraphUtil import filter_stack
+from _vendoring.altgraph import GraphError
+from _vendoring.altgraph.Graph import Graph
+from _vendoring.altgraph.GraphUtil import filter_stack
 
 
 class ObjectGraph(object):

lib/spack/external/_vendoring/altgraph/__init__.py

@@ -1,18 +1,18 @@
 """
-altgraph - a python graph library
+_vendoring.altgraph - a python graph library
 =================================
 
-altgraph is a fork of `graphlib <http://pygraphlib.sourceforge.net>`_ tailored
+_vendoring.altgraph is a fork of `graphlib <http://pygraphlib.sourceforge.net>`_ tailored
 to use newer Python 2.3+ features, including additional support used by the
-py2app suite (modulegraph and macholib, specifically).
+py2app suite (modulegraph and _vendoring.macholib, specifically).
 
-altgraph is a python based graph (network) representation and manipulation
+_vendoring.altgraph is a python based graph (network) representation and manipulation
 package.  It has started out as an extension to the
 `graph_lib module
 <http://www.ece.arizona.edu/~denny/python_nest/graph_lib_1.0.1.html>`_
 written by Nathan Denny it has been significantly optimized and expanded.
 
-The :class:`altgraph.Graph.Graph` class is loosely modeled after the
+The :class:`_vendoring.altgraph.Graph.Graph` class is loosely modeled after the
 `LEDA <http://www.algorithmic-solutions.com/enleda.htm>`_
 (Library of Efficient Datatypes) representation. The library
 includes methods for constructing graphs, BFS and DFS traversals,
@@ -22,22 +22,22 @@
 
 The package contains the following modules:
 
-    -  the :py:mod:`altgraph.Graph` module contains the
-       :class:`~altgraph.Graph.Graph` class that stores the graph data
+    -  the :py:mod:`_vendoring.altgraph.Graph` module contains the
+       :class:`~_vendoring.altgraph.Graph.Graph` class that stores the graph data
 
-    -  the :py:mod:`altgraph.GraphAlgo` module implements graph algorithms
-       operating on graphs (:py:class:`~altgraph.Graph.Graph`} instances)
+    -  the :py:mod:`_vendoring.altgraph.GraphAlgo` module implements graph algorithms
+       operating on graphs (:py:class:`~_vendoring.altgraph.Graph.Graph`} instances)
 
-    -  the :py:mod:`altgraph.GraphStat` module contains functions for
+    -  the :py:mod:`_vendoring.altgraph.GraphStat` module contains functions for
        computing statistical measures on graphs
 
-    -  the :py:mod:`altgraph.GraphUtil` module contains functions for
+    -  the :py:mod:`_vendoring.altgraph.GraphUtil` module contains functions for
        generating, reading and saving graphs
 
-    -  the :py:mod:`altgraph.Dot` module  contains functions for displaying
+    -  the :py:mod:`_vendoring.altgraph.Dot` module  contains functions for displaying
        graphs via `graphviz <http://www.research.att.com/sw/tools/graphviz/>`_
 
-    -  the :py:mod:`altgraph.ObjectGraph` module implements a graph of
+    -  the :py:mod:`_vendoring.altgraph.ObjectGraph` module implements a graph of
        objects with a unique identifier
 
 Installation
@@ -62,7 +62,7 @@
 Lets assume that we want to analyze the graph below (links to the full picture)
 GRAPH_IMG.  Our script then might look the following way::
 
-    from altgraph import Graph, GraphAlgo, Dot
+    from _vendoring.altgraph import Graph, GraphAlgo, Dot
 
     # these are the edges
     edges = [ (1,2), (2,4), (1,3), (2,4), (3,4), (4,5), (6,5),
@@ -141,7 +141,7 @@
 """
 import pkg_resources
 
-__version__ = pkg_resources.require("altgraph")[0].version
+__version__ = pkg_resources.require("_vendoring.altgraph")[0].version
 
 
 class GraphError(ValueError):

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

@@ -0,0 +1,3 @@
+"""Init file to avoid namespace packages"""
+
+__version__ = "0.2.5"

lib/spack/external/_vendoring/archspec/cli.py

@@ -9,8 +9,8 @@
 import argparse
 import typing
 
-import archspec
-import archspec.cpu
+import _vendoring.archspec
+import _vendoring.archspec.cpu
 
 
 def _make_parser() -> argparse.ArgumentParser:
@@ -24,7 +24,7 @@ def _make_parser() -> argparse.ArgumentParser:
         "-V",
         help="Show the version and exit.",
         action="version",
-        version=f"archspec, version {archspec.__version__}",
+        version=f"archspec, version {_vendoring.archspec.__version__}",
     )
     parser.add_argument("--help", "-h", help="Show the help and exit.", action="help")
 
@@ -45,9 +45,9 @@ def _make_parser() -> argparse.ArgumentParser:
 
 
 def cpu() -> int:
-    """Run the `archspec cpu` subcommand."""
+    """Run the `_vendoring.archspec.cpu` subcommand."""
     try:
-        print(archspec.cpu.host())
+        print(_vendoring.archspec.cpu.host())
     except FileNotFoundError as exc:
         print(exc)
         return 1

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

@@ -8,9 +8,9 @@
 import re
 import warnings
 
-import archspec
-import archspec.cpu.alias
-import archspec.cpu.schema
+import _vendoring.archspec
+import _vendoring.archspec.cpu.alias
+import _vendoring.archspec.cpu.schema
 
 from .alias import FEATURE_ALIASES
 from .schema import LazyDictionary
@@ -384,7 +384,7 @@ def fill_target_from_dict(name, data, targets):
         )
 
     known_targets = {}
-    data = archspec.cpu.schema.TARGETS_JSON["microarchitectures"]
+    data = _vendoring.archspec.cpu.schema.TARGETS_JSON["microarchitectures"]
     for name in data:
         if name in known_targets:
             # name was already brought in as ancestor to a target

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

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

lib/spack/external/_vendoring/attr/_make.py

@@ -38,7 +38,7 @@
     "typing.ClassVar",
     "t.ClassVar",
     "ClassVar",
-    "typing_extensions.ClassVar",
+    "_vendoring.typing_extensions.ClassVar",
 )
 # we don't use a double-underscore prefix because that triggers
 # name mangling when trying to create a slot for the field

lib/spack/external/_vendoring/attrs/__init__.py

@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: MIT
 
-from attr import (
+from _vendoring.attr import (
     NOTHING,
     Attribute,
     Factory,
@@ -28,7 +28,7 @@
     resolve_types,
     validate,
 )
-from attr._next_gen import asdict, astuple
+from _vendoring.attr._next_gen import asdict, astuple
 
 from . import converters, exceptions, filters, setters, validators
 

lib/spack/external/_vendoring/attrs/converters.py

@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: MIT
 
-from attr.converters import *  # noqa
+from _vendoring.attr.converters import *  # noqa

lib/spack/external/_vendoring/attrs/exceptions.py

@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: MIT
 
-from attr.exceptions import *  # noqa
+from _vendoring.attr.exceptions import *  # noqa

lib/spack/external/_vendoring/attrs/filters.py

@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: MIT
 
-from attr.filters import *  # noqa
+from _vendoring.attr.filters import *  # noqa

lib/spack/external/_vendoring/attrs/setters.py

@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: MIT
 
-from attr.setters import *  # noqa
+from _vendoring.attr.setters import *  # noqa

lib/spack/external/_vendoring/attrs/validators.py

@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: MIT
 
-from attr.validators import *  # noqa
+from _vendoring.attr.validators import *  # noqa

lib/spack/external/_vendoring/jinja2/bccache.py

@@ -19,7 +19,7 @@
 from types import CodeType
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
     class _MemcachedClient(te.Protocol):
@@ -101,7 +101,7 @@ def bytecode_to_string(self) -> bytes:
 class BytecodeCache:
     """To implement your own bytecode cache you have to subclass this class
     and override :meth:`load_bytecode` and :meth:`dump_bytecode`.  Both of
-    these methods are passed a :class:`~jinja2.bccache.Bucket`.
+    these methods are passed a :class:`~_vendoring.jinja2.bccache.Bucket`.
 
     A very basic bytecode cache that saves the bytecode on the file system::
 
@@ -193,7 +193,7 @@ class FileSystemBytecodeCache(BytecodeCache):
     is created for the user in the system temp directory.
 
     The pattern can be used to have multiple separate caches operate on the
-    same directory.  The default pattern is ``'__jinja2_%s.cache'``.  ``%s``
+    same directory.  The default pattern is ``'___vendoring.jinja2_%s.cache'``.  ``%s``
     is replaced with the cache key.
 
     >>> bcc = FileSystemBytecodeCache('/tmp/jinja_cache', '%s.cache')
@@ -202,7 +202,7 @@ class FileSystemBytecodeCache(BytecodeCache):
     """
 
     def __init__(
-        self, directory: t.Optional[str] = None, pattern: str = "__jinja2_%s.cache"
+        self, directory: t.Optional[str] = None, pattern: str = "___vendoring.jinja2_%s.cache"
     ) -> None:
         if directory is None:
             directory = self._get_default_cache_dir()
@@ -225,7 +225,7 @@ def _unsafe_dir() -> "te.NoReturn":
         if not hasattr(os, "getuid"):
             _unsafe_dir()
 
-        dirname = f"_jinja2-cache-{os.getuid()}"
+        dirname = f"__vendoring.jinja2-cache-{os.getuid()}"
         actual_dir = os.path.join(tmpdir, dirname)
 
         try:
@@ -332,7 +332,7 @@ class MemcachedBytecodeCache(BytecodeCache):
     def __init__(
         self,
         client: "_MemcachedClient",
-        prefix: str = "jinja2/bytecode/",
+        prefix: str = "_vendoring.jinja2/bytecode/",
         timeout: t.Optional[int] = None,
         ignore_memcache_errors: bool = True,
     ):

lib/spack/external/_vendoring/jinja2/compiler.py

@@ -6,8 +6,8 @@
 from itertools import chain
 from keyword import iskeyword as is_python_keyword
 
-from markupsafe import escape
-from markupsafe import Markup
+from _vendoring.markupsafe import escape
+from _vendoring.markupsafe import Markup
 
 from . import nodes
 from .exceptions import TemplateAssertionError
@@ -23,7 +23,7 @@
 from .visitor import NodeVisitor
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
 F = t.TypeVar("F", bound=t.Callable[..., t.Any])
@@ -836,7 +836,7 @@ def visit_Template(
             exported_names = sorted(exported)
 
         self.writeline("from __future__ import generator_stop")  # Python < 3.7
-        self.writeline("from jinja2.runtime import " + ", ".join(exported_names))
+        self.writeline("from _vendoring.jinja2.runtime import " + ", ".join(exported_names))
 
         # if we want a deferred initialization we cannot move the
         # environment into a local name

lib/spack/external/_vendoring/jinja2/defaults.py

@@ -8,7 +8,7 @@
 from .utils import Namespace
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
 
 # defaults for the parser / lexer
 BLOCK_START_STRING = "{%"

lib/spack/external/_vendoring/jinja2/environment.py

@@ -12,7 +12,7 @@
 from functools import reduce
 from types import CodeType
 
-from markupsafe import Markup
+from _vendoring.markupsafe import Markup
 
 from . import nodes
 from .compiler import CodeGenerator
@@ -55,7 +55,7 @@
 from .utils import missing
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .bccache import BytecodeCache
     from .ext import Extension
     from .loaders import BaseLoader
@@ -126,7 +126,7 @@ def _environment_config_check(environment: "Environment") -> "Environment":
     """Perform a sanity check on the environment."""
     assert issubclass(
         environment.undefined, Undefined
-    ), "'undefined' must be a subclass of 'jinja2.Undefined'."
+    ), "'undefined' must be a subclass of '_vendoring.jinja2.Undefined'."
     assert (
         environment.block_start_string
         != environment.variable_start_string
@@ -221,7 +221,7 @@ class Environment:
         `autoescape`
             If set to ``True`` the XML/HTML autoescaping feature is enabled by
             default.  For more details about autoescaping see
-            :class:`~markupsafe.Markup`.  As of Jinja 2.4 this can also
+            :class:`~_vendoring.markupsafe.Markup`.  As of Jinja 2.4 this can also
             be a callable that is passed the template name and has to
             return ``True`` or ``False`` depending on autoescape should be
             enabled by default.
@@ -264,7 +264,7 @@ class Environment:
 
     #: if this environment is sandboxed.  Modifying this variable won't make
     #: the environment sandboxed though.  For a real sandboxed environment
-    #: have a look at jinja2.sandbox.  This flag alone controls the code
+    #: have a look at _vendoring.jinja2.sandbox.  This flag alone controls the code
     #: generation by the compiler.
     sandboxed = False
 
@@ -279,11 +279,11 @@ class Environment:
     shared = False
 
     #: the class that is used for code generation.  See
-    #: :class:`~jinja2.compiler.CodeGenerator` for more information.
+    #: :class:`~_vendoring.jinja2.compiler.CodeGenerator` for more information.
     code_generator_class: t.Type["CodeGenerator"] = CodeGenerator
 
     #: the context class that is used for templates.  See
-    #: :class:`~jinja2.runtime.Context` for more information.
+    #: :class:`~_vendoring.jinja2.runtime.Context` for more information.
     context_class: t.Type[Context] = Context
 
     template_class: t.Type["Template"]
@@ -650,7 +650,7 @@ def _tokenize(
         state: t.Optional[str] = None,
     ) -> TokenStream:
         """Called by the parser to do the preprocessing and filtering
-        for all the extensions.  Returns a :class:`~jinja2.lexer.TokenStream`.
+        for all the extensions.  Returns a :class:`~_vendoring.jinja2.lexer.TokenStream`.
         """
         source = self.preprocess(source, name, filename)
         stream = self.lexer.tokenize(source, name, filename, state)
@@ -1547,7 +1547,7 @@ def __repr__(self) -> str:
 
 
 class TemplateExpression:
-    """The :meth:`jinja2.Environment.compile_expression` method returns an
+    """The :meth:`_vendoring.jinja2.Environment.compile_expression` method returns an
     instance of this object.  It encapsulates the expression-like access
     to the template with an expression it wraps.
     """

lib/spack/external/_vendoring/jinja2/ext.py

@@ -4,7 +4,7 @@
 import typing as t
 import warnings
 
-from markupsafe import Markup
+from _vendoring.markupsafe import Markup
 
 from . import defaults
 from . import nodes
@@ -18,7 +18,7 @@
 from .utils import pass_context
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .lexer import Token
     from .lexer import TokenStream
     from .parser import Parser
@@ -108,10 +108,10 @@ def preprocess(
     def filter_stream(
         self, stream: "TokenStream"
     ) -> t.Union["TokenStream", t.Iterable["Token"]]:
-        """It's passed a :class:`~jinja2.lexer.TokenStream` that can be used
+        """It's passed a :class:`~_vendoring.jinja2.lexer.TokenStream` that can be used
         to filter tokens returned.  This method has to return an iterable of
-        :class:`~jinja2.lexer.Token`\\s, but it doesn't have to return a
-        :class:`~jinja2.lexer.TokenStream`.
+        :class:`~_vendoring.jinja2.lexer.Token`\\s, but it doesn't have to return a
+        :class:`~_vendoring.jinja2.lexer.TokenStream`.
         """
         return stream
 
@@ -145,7 +145,7 @@ def call_method(
         lineno: t.Optional[int] = None,
     ) -> nodes.Call:
         """Call a method of the extension.  This is a shortcut for
-        :meth:`attr` + :class:`jinja2.nodes.Call`.
+        :meth:`attr` + :class:`_vendoring.jinja2.nodes.Call`.
         """
         if args is None:
             args = []
@@ -629,9 +629,9 @@ class DebugExtension(Extension):
 
     .. code-block:: text
 
-        {'context': {'cycler': <class 'jinja2.utils.Cycler'>,
+        {'context': {'cycler': <class '_vendoring.jinja2.utils.Cycler'>,
                      ...,
-                     'namespace': <class 'jinja2.utils.Namespace'>},
+                     'namespace': <class '_vendoring.jinja2.utils.Namespace'>},
          'filters': ['abs', 'attr', 'batch', 'capitalize', 'center', 'count', 'd',
                      ..., 'urlencode', 'urlize', 'wordcount', 'wordwrap', 'xmlattr'],
          'tests': ['!=', '<', '<=', '==', '>', '>=', 'callable', 'defined',
@@ -679,7 +679,7 @@ def extract_from_ast(
 
     This example explains the behavior:
 
-    >>> from jinja2 import Environment
+    >>> from _vendoring.jinja2 import Environment
     >>> env = Environment()
     >>> node = env.parse('{{ (_("foo"), _(), ngettext("foo", "bar", 42)) }}')
     >>> list(extract_from_ast(node))

lib/spack/external/_vendoring/jinja2/filters.py

@@ -9,9 +9,9 @@
 from itertools import chain
 from itertools import groupby
 
-from markupsafe import escape
-from markupsafe import Markup
-from markupsafe import soft_str
+from _vendoring.markupsafe import escape
+from _vendoring.markupsafe import Markup
+from _vendoring.markupsafe import soft_str
 
 from .async_utils import async_variant
 from .async_utils import auto_aiter
@@ -28,7 +28,7 @@
 from .utils import urlize
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
     from .nodes import EvalContext
     from .runtime import Context
@@ -48,7 +48,7 @@ def contextfilter(f: F) -> F:
     """Pass the context as the first argument to the decorated function.
 
     .. deprecated:: 3.0
-        Will be removed in Jinja 3.1. Use :func:`~jinja2.pass_context`
+        Will be removed in Jinja 3.1. Use :func:`~_vendoring.jinja2.pass_context`
         instead.
     """
     warnings.warn(
@@ -66,7 +66,7 @@ def evalcontextfilter(f: F) -> F:
 
     .. deprecated:: 3.0
         Will be removed in Jinja 3.1. Use
-        :func:`~jinja2.pass_eval_context` instead.
+        :func:`~_vendoring.jinja2.pass_eval_context` instead.
 
     .. versionadded:: 2.4
     """
@@ -85,7 +85,7 @@ def environmentfilter(f: F) -> F:
 
     .. deprecated:: 3.0
         Will be removed in Jinja 3.1. Use
-        :func:`~jinja2.pass_environment` instead.
+        :func:`~_vendoring.jinja2.pass_environment` instead.
     """
     warnings.warn(
         "'environmentfilter' is renamed to 'pass_environment', the old"
@@ -547,10 +547,10 @@ def do_default(
         {{ ''|default('the string was empty', true) }}
 
     .. versionchanged:: 2.11
-       It's now possible to configure the :class:`~jinja2.Environment` with
-       :class:`~jinja2.ChainableUndefined` to make the `default` filter work
+       It's now possible to configure the :class:`~_vendoring.jinja2.Environment` with
+       :class:`~_vendoring.jinja2.ChainableUndefined` to make the `default` filter work
        on nested elements and attributes that may contain undefined values
-       in the chain without getting an :exc:`~jinja2.UndefinedError`.
+       in the chain without getting an :exc:`~_vendoring.jinja2.UndefinedError`.
     """
     if isinstance(value, Undefined) or (boolean and not value):
         return default_value

lib/spack/external/_vendoring/jinja2/lexer.py

@@ -14,7 +14,7 @@
 from .utils import LRUCache
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
 # cache for the lexers. Exists in order to be able to have multiple
@@ -400,7 +400,7 @@ def close(self) -> None:
 
     def expect(self, expr: str) -> Token:
         """Expect a given token type and return it.  This accepts the same
-        argument as :meth:`jinja2.lexer.Token.test`.
+        argument as :meth:`_vendoring.jinja2.lexer.Token.test`.
         """
         if not self.current.test(expr):
             expr = describe_token_expr(expr)

lib/spack/external/_vendoring/jinja2/loaders.py

@@ -47,7 +47,7 @@ class BaseLoader:
     A very basic example for a loader that looks up templates on the file
     system could look like this::
 
-        from jinja2 import BaseLoader, TemplateNotFound
+        from _vendoring.jinja2 import BaseLoader, TemplateNotFound
         from os.path import join, exists, getmtime
 
         class MyLoader(BaseLoader):
@@ -594,7 +594,7 @@ class ModuleLoader(BaseLoader):
     def __init__(
         self, path: t.Union[str, os.PathLike, t.Sequence[t.Union[str, os.PathLike]]]
     ) -> None:
-        package_name = f"_jinja2_module_templates_{id(self):x}"
+        package_name = f"__vendoring.jinja2_module_templates_{id(self):x}"
 
         # create a fake module that looks for the templates in the
         # path given.

lib/spack/external/_vendoring/jinja2/meta.py

@@ -36,7 +36,7 @@ def find_undeclared_variables(ast: nodes.Template) -> t.Set[str]:
     variables will be used depending on the path the execution takes at
     runtime, all variables are returned.
 
-    >>> from jinja2 import Environment, meta
+    >>> from _vendoring.jinja2 import Environment, meta
     >>> env = Environment()
     >>> ast = env.parse('{% set foo = 42 %}{{ bar + foo }}')
     >>> meta.find_undeclared_variables(ast) == {'bar'}
@@ -64,7 +64,7 @@ def find_referenced_templates(ast: nodes.Template) -> t.Iterator[t.Optional[str]
     imports.  If dynamic inheritance or inclusion is used, `None` will be
     yielded.
 
-    >>> from jinja2 import Environment, meta
+    >>> from _vendoring.jinja2 import Environment, meta
     >>> env = Environment()
     >>> ast = env.parse('{% extends "layout.html" %}{% include helper %}')
     >>> list(meta.find_referenced_templates(ast))

lib/spack/external/_vendoring/jinja2/nodes.py

@@ -7,12 +7,12 @@
 import typing as t
 from collections import deque
 
-from markupsafe import Markup
+from _vendoring.markupsafe import Markup
 
 from .utils import _PassArg
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
 _NodeBound = t.TypeVar("_NodeBound", bound="Node")
@@ -1041,7 +1041,7 @@ class ExtensionAttribute(Expr):
     The identifier is the identifier of the :class:`Extension`.
 
     This node is usually constructed by calling the
-    :meth:`~jinja2.ext.Extension.attr` method on an extension.
+    :meth:`~_vendoring.jinja2.ext.Extension.attr` method on an extension.
     """
 
     fields = ("identifier", "name")
@@ -1063,7 +1063,7 @@ class ImportedName(Expr):
 class InternalName(Expr):
     """An internal name in the compiler.  You cannot create these nodes
     yourself but the parser provides a
-    :meth:`~jinja2.parser.Parser.free_identifier` method that creates
+    :meth:`~_vendoring.jinja2.parser.Parser.free_identifier` method that creates
     a new identifier for you.  This identifier is not available from the
     template and is not treated specially by the compiler.
     """
@@ -1114,7 +1114,7 @@ def as_const(
 class ContextReference(Expr):
     """Returns the current template context.  It can be used like a
     :class:`Name` node, with a ``'load'`` ctx and will return the
-    current :class:`~jinja2.runtime.Context` object.
+    current :class:`~_vendoring.jinja2.runtime.Context` object.
 
     Here an example that assigns the current template name to a
     variable named `foo`::
@@ -1123,7 +1123,7 @@ class ContextReference(Expr):
                Getattr(ContextReference(), 'name'))
 
     This is basically equivalent to using the
-    :func:`~jinja2.pass_context` decorator when using the high-level
+    :func:`~_vendoring.jinja2.pass_context` decorator when using the high-level
     API, which causes a reference to the context to be passed as the
     first argument to a function.
     """
@@ -1188,7 +1188,7 @@ class EvalContextModifier(Stmt):
 class ScopedEvalContextModifier(EvalContextModifier):
     """Modifies the eval context and reverts it later.  Works exactly like
     :class:`EvalContextModifier` but will only modify the
-    :class:`~jinja2.nodes.EvalContext` for nodes in the :attr:`body`.
+    :class:`~_vendoring.jinja2.nodes.EvalContext` for nodes in the :attr:`body`.
     """
 
     fields = ("body",)

lib/spack/external/_vendoring/jinja2/parser.py

@@ -9,7 +9,7 @@
 from .lexer import describe_token_expr
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
 _ImportInclude = t.TypeVar("_ImportInclude", nodes.Import, nodes.Include)
@@ -156,7 +156,7 @@ def is_tuple_end(
         return False
 
     def free_identifier(self, lineno: t.Optional[int] = None) -> nodes.InternalName:
-        """Return a new free identifier as :class:`~jinja2.nodes.InternalName`."""
+        """Return a new free identifier as :class:`~_vendoring.jinja2.nodes.InternalName`."""
         self._last_identifier += 1
         rv = object.__new__(nodes.InternalName)
         nodes.Node.__init__(rv, f"fi{self._last_identifier}", lineno=lineno)
@@ -687,7 +687,7 @@ def parse_tuple(
         explicit_parentheses: bool = False,
     ) -> t.Union[nodes.Tuple, nodes.Expr]:
         """Works like `parse_expression` but if multiple expressions are
-        delimited by a comma a :class:`~jinja2.nodes.Tuple` node is created.
+        delimited by a comma a :class:`~_vendoring.jinja2.nodes.Tuple` node is created.
         This method could also return a regular expression instead of a tuple
         if no commas where found.
 

lib/spack/external/_vendoring/jinja2/runtime.py

@@ -5,9 +5,9 @@
 from collections import abc
 from itertools import chain
 
-from markupsafe import escape  # noqa: F401
-from markupsafe import Markup
-from markupsafe import soft_str
+from _vendoring.markupsafe import escape  # noqa: F401
+from _vendoring.markupsafe import Markup
+from _vendoring.markupsafe import soft_str
 
 from .async_utils import auto_aiter
 from .async_utils import auto_await  # noqa: F401
@@ -28,7 +28,7 @@
 
 if t.TYPE_CHECKING:
     import logging
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
     from .environment import Environment
 
     class LoopRenderFunc(te.Protocol):
@@ -849,7 +849,7 @@ class Undefined:
     >>> foo + 42
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
     """
 
     __slots__ = (
@@ -1020,7 +1020,7 @@ class ChainableUndefined(Undefined):
     >>> foo.bar['baz'] + 42
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
 
     .. versionadded:: 2.11.0
     """
@@ -1047,7 +1047,7 @@ class DebugUndefined(Undefined):
     >>> foo + 42
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
     """
 
     __slots__ = ()
@@ -1077,15 +1077,15 @@ class StrictUndefined(Undefined):
     >>> str(foo)
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
     >>> not foo
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
     >>> foo + 42
     Traceback (most recent call last):
       ...
-    jinja2.exceptions.UndefinedError: 'foo' is undefined
+    _vendoring.jinja2.exceptions.UndefinedError: 'foo' is undefined
     """
 
     __slots__ = ()

lib/spack/external/_vendoring/jinja2/sandbox.py

@@ -9,8 +9,8 @@
 from collections import deque
 from string import Formatter
 
-from markupsafe import EscapeFormatter
-from markupsafe import Markup
+from _vendoring.markupsafe import EscapeFormatter
+from _vendoring.markupsafe import Markup
 
 from .environment import Environment
 from .exceptions import SecurityError
@@ -128,7 +128,7 @@ def is_internal_attribute(obj: t.Any, attr: str) -> bool:
     python objects.  This is useful if the environment method
     :meth:`~SandboxedEnvironment.is_safe_attribute` is overridden.
 
-    >>> from jinja2.sandbox import is_internal_attribute
+    >>> from _vendoring.jinja2.sandbox import is_internal_attribute
     >>> is_internal_attribute(str, "mro")
     True
     >>> is_internal_attribute(str, "upper")

lib/spack/external/_vendoring/jinja2/utils.py

@@ -12,10 +12,10 @@
 from types import CodeType
 from urllib.parse import quote_from_bytes
 
-import markupsafe
+import _vendoring.markupsafe
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
 
 F = t.TypeVar("F", bound=t.Callable[..., t.Any])
 
@@ -28,7 +28,7 @@
 
 
 def pass_context(f: F) -> F:
-    """Pass the :class:`~jinja2.runtime.Context` as the first argument
+    """Pass the :class:`~_vendoring.jinja2.runtime.Context` as the first argument
     to the decorated function when called while rendering a template.
 
     Can be used on functions, filters, and tests.
@@ -45,7 +45,7 @@ def pass_context(f: F) -> F:
 
 
 def pass_eval_context(f: F) -> F:
-    """Pass the :class:`~jinja2.nodes.EvalContext` as the first argument
+    """Pass the :class:`~_vendoring.jinja2.nodes.EvalContext` as the first argument
     to the decorated function when called while rendering a template.
     See :ref:`eval-context`.
 
@@ -62,7 +62,7 @@ def pass_eval_context(f: F) -> F:
 
 
 def pass_environment(f: F) -> F:
-    """Pass the :class:`~jinja2.Environment` as the first argument to
+    """Pass the :class:`~_vendoring.jinja2.Environment` as the first argument to
     the decorated function when called while rendering a template.
 
     Can be used on functions, filters, and tests.
@@ -104,7 +104,7 @@ def contextfunction(f: F) -> F:
     """Pass the context as the first argument to the decorated function.
 
     .. deprecated:: 3.0
-        Will be removed in Jinja 3.1. Use :func:`~jinja2.pass_context`
+        Will be removed in Jinja 3.1. Use :func:`~_vendoring.jinja2.pass_context`
         instead.
     """
     warnings.warn(
@@ -122,7 +122,7 @@ def evalcontextfunction(f: F) -> F:
 
     .. deprecated:: 3.0
         Will be removed in Jinja 3.1. Use
-        :func:`~jinja2.pass_eval_context` instead.
+        :func:`~_vendoring.jinja2.pass_eval_context` instead.
 
     .. versionadded:: 2.4
     """
@@ -141,7 +141,7 @@ def environmentfunction(f: F) -> F:
 
     .. deprecated:: 3.0
         Will be removed in Jinja 3.1. Use
-        :func:`~jinja2.pass_environment` instead.
+        :func:`~_vendoring.jinja2.pass_environment` instead.
     """
     warnings.warn(
         "'environmentfunction' is renamed to 'pass_environment', the"
@@ -335,9 +335,9 @@ def trim_url(x: str) -> str:
         def trim_url(x: str) -> str:
             return x
 
-    words = re.split(r"(\s+)", str(markupsafe.escape(text)))
-    rel_attr = f' rel="{markupsafe.escape(rel)}"' if rel else ""
-    target_attr = f' target="{markupsafe.escape(target)}"' if target else ""
+    words = re.split(r"(\s+)", str(_vendoring.markupsafe.escape(text)))
+    rel_attr = f' rel="{_vendoring.markupsafe.escape(rel)}"' if rel else ""
+    target_attr = f' target="{_vendoring.markupsafe.escape(target)}"' if target else ""
 
     for i, word in enumerate(words):
         head, middle, tail = "", word, ""
@@ -455,8 +455,8 @@ def generate_lorem_ipsum(
 
     if not html:
         return "\n\n".join(result)
-    return markupsafe.Markup(
-        "\n".join(f"<p>{markupsafe.escape(x)}</p>" for x in result)
+    return _vendoring.markupsafe.Markup(
+        "\n".join(f"<p>{_vendoring.markupsafe.escape(x)}</p>" for x in result)
     )
 
 
@@ -658,7 +658,7 @@ def select_autoescape(
     If you want to enable it for all templates created from strings or
     for all templates with `.html` and `.xml` extensions::
 
-        from jinja2 import Environment, select_autoescape
+        from _vendoring.jinja2 import Environment, select_autoescape
         env = Environment(autoescape=select_autoescape(
             enabled_extensions=('html', 'xml'),
             default_for_string=True,
@@ -667,7 +667,7 @@ def select_autoescape(
     Example configuration to turn it on at all times except if the template
     ends with `.txt`::
 
-        from jinja2 import Environment, select_autoescape
+        from _vendoring.jinja2 import Environment, select_autoescape
         env = Environment(autoescape=select_autoescape(
             disabled_extensions=('txt',),
             default_for_string=True,
@@ -703,10 +703,10 @@ def autoescape(template_name: t.Optional[str]) -> bool:
 
 def htmlsafe_json_dumps(
     obj: t.Any, dumps: t.Optional[t.Callable[..., str]] = None, **kwargs: t.Any
-) -> markupsafe.Markup:
+) -> _vendoring.markupsafe.Markup:
     """Serialize an object to a string of JSON with :func:`json.dumps`,
     then replace HTML-unsafe characters with Unicode escapes and mark
-    the result safe with :class:`~markupsafe.Markup`.
+    the result safe with :class:`~_vendoring.markupsafe.Markup`.
 
     This is available in templates as the ``|tojson`` filter.
 
@@ -732,7 +732,7 @@ def htmlsafe_json_dumps(
     if dumps is None:
         dumps = json.dumps
 
-    return markupsafe.Markup(
+    return _vendoring.markupsafe.Markup(
         dumps(obj, **kwargs)
         .replace("<", "\\u003c")
         .replace(">", "\\u003e")
@@ -833,11 +833,11 @@ def __repr__(self) -> str:
         return f"<Namespace {self.__attrs!r}>"
 
 
-class Markup(markupsafe.Markup):
+class Markup(_vendoring.markupsafe.Markup):
     def __new__(cls, base="", encoding=None, errors="strict"):  # type: ignore
         warnings.warn(
-            "'jinja2.Markup' is deprecated and will be removed in Jinja"
-            " 3.1. Import 'markupsafe.Markup' instead.",
+            "'_vendoring.jinja2.Markup' is deprecated and will be removed in Jinja"
+            " 3.1. Import '_vendoring.markupsafe.Markup' instead.",
             DeprecationWarning,
             stacklevel=2,
         )
@@ -846,9 +846,9 @@ def __new__(cls, base="", encoding=None, errors="strict"):  # type: ignore
 
 def escape(s: t.Any) -> str:
     warnings.warn(
-        "'jinja2.escape' is deprecated and will be removed in Jinja"
-        " 3.1. Import 'markupsafe.escape' instead.",
+        "'_vendoring.jinja2.escape' is deprecated and will be removed in Jinja"
+        " 3.1. Import '_vendoring.markupsafe.escape' instead.",
         DeprecationWarning,
         stacklevel=2,
     )
-    return markupsafe.escape(s)
+    return _vendoring.markupsafe.escape(s)

lib/spack/external/_vendoring/jinja2/visitor.py

@@ -6,7 +6,7 @@
 from .nodes import Node
 
 if t.TYPE_CHECKING:
-    import typing_extensions as te
+    import _vendoring.typing_extensions as te
 
     class VisitCallable(te.Protocol):
         def __call__(self, node: Node, *args: t.Any, **kwargs: t.Any) -> t.Any:

lib/spack/external/_vendoring/jsonschema.pyi

@@ -1 +0,0 @@
-from jsonschema import *

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

@@ -8,18 +8,18 @@
 instance under a schema, and will create a validator for you.
 """
 
-from jsonschema.exceptions import (
+from _vendoring.jsonschema.exceptions import (
     ErrorTree, FormatError, RefResolutionError, SchemaError, ValidationError
 )
-from jsonschema._format import (
+from _vendoring.jsonschema._format import (
     FormatChecker,
     draft3_format_checker,
     draft4_format_checker,
     draft6_format_checker,
     draft7_format_checker,
 )
-from jsonschema._types import TypeChecker
-from jsonschema.validators import (
+from _vendoring.jsonschema._types import TypeChecker
+from _vendoring.jsonschema.validators import (
     Draft3Validator,
     Draft4Validator,
     Draft6Validator,

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

@@ -1,2 +1,2 @@
-from jsonschema.cli import main
+from _vendoring.jsonschema.cli import main
 main()

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

@@ -3,8 +3,8 @@
 import socket
 import struct
 
-from jsonschema.compat import str_types
-from jsonschema.exceptions import FormatError
+from _vendoring.jsonschema.compat import str_types
+from _vendoring.jsonschema.exceptions import FormatError
 
 
 class FormatChecker(object):

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

@@ -1,6 +1,6 @@
-from jsonschema import _utils
-from jsonschema.compat import iteritems
-from jsonschema.exceptions import ValidationError
+from _vendoring.jsonschema import _utils
+from _vendoring.jsonschema.compat import iteritems
+from _vendoring.jsonschema.exceptions import ValidationError
 
 
 def dependencies_draft3(validator, dependencies, instance, schema):

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

@@ -9,7 +9,7 @@
 
 import sys
 
-from jsonschema.compat import PY3
+from _vendoring.jsonschema.compat import PY3
 
 
 class _NoModuleFound(Exception):

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

@@ -1,10 +1,10 @@
 import numbers
 
-from pyrsistent import pmap
-import attr
+from _vendoring.pyrsistent import pmap
+import _vendoring.attr
 
-from jsonschema.compat import int_types, str_types
-from jsonschema.exceptions import UndefinedTypeCheck
+from _vendoring.jsonschema.compat import int_types, str_types
+from _vendoring.jsonschema.exceptions import UndefinedTypeCheck
 
 
 def is_array(checker, instance):
@@ -45,7 +45,7 @@ def is_any(checker, instance):
     return True
 
 
-@attr.s(frozen=True)
+@_vendoring.attr.s(frozen=True)
 class TypeChecker(object):
     """
     A ``type`` property checker.
@@ -61,7 +61,7 @@ class TypeChecker(object):
 
             The initial mapping of types to their checking functions.
     """
-    _type_checkers = attr.ib(default=pmap(), converter=pmap)
+    _type_checkers = _vendoring.attr.ib(default=pmap(), converter=pmap)
 
     def is_type(self, instance, type):
         """
@@ -131,7 +131,7 @@ def redefine_many(self, definitions=()):
 
             A new `TypeChecker` instance.
         """
-        return attr.evolve(
+        return _vendoring.attr.evolve(
             self, type_checkers=self._type_checkers.update(definitions),
         )
 
@@ -162,7 +162,7 @@ def remove(self, *types):
                 checkers = checkers.remove(each)
             except KeyError:
                 raise UndefinedTypeCheck(each)
-        return attr.evolve(self, type_checkers=checkers)
+        return _vendoring.attr.evolve(self, type_checkers=checkers)
 
 
 draft3_type_checker = TypeChecker(

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

@@ -3,7 +3,7 @@
 import pkgutil
 import re
 
-from jsonschema.compat import MutableMapping, str_types, urlsplit
+from _vendoring.jsonschema.compat import MutableMapping, str_types, urlsplit
 
 
 class URIDict(MutableMapping):
@@ -51,7 +51,7 @@ def load_schema(name):
     Load a schema from ./schemas/``name``.json and return it.
     """
 
-    data = pkgutil.get_data("jsonschema", "schemas/{0}.json".format(name))
+    data = pkgutil.get_data("_vendoring.jsonschema", "schemas/{0}.json".format(name))
     return json.loads(data.decode("utf-8"))
 
 

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

@@ -1,6 +1,6 @@
 import re
 
-from jsonschema._utils import (
+from _vendoring.jsonschema._utils import (
     ensure_list,
     equal,
     extras_msg,
@@ -9,8 +9,8 @@
     unbool,
     uniq,
 )
-from jsonschema.exceptions import FormatError, ValidationError
-from jsonschema.compat import iteritems
+from _vendoring.jsonschema.exceptions import FormatError, ValidationError
+from _vendoring.jsonschema.compat import iteritems
 
 
 def patternProperties(validator, patternProperties, instance, schema):

lib/spack/external/_vendoring/jsonschema/benchmarks/issue232.py

@@ -6,10 +6,10 @@
 """
 from twisted.python.filepath import FilePath
 from pyperf import Runner
-from pyrsistent import m
+from _vendoring.pyrsistent import m
 
-from jsonschema.tests._suite import Version
-import jsonschema
+from _vendoring.jsonschema.tests._suite import Version
+import _vendoring.jsonschema
 
 
 issue232 = Version(

lib/spack/external/_vendoring/jsonschema/benchmarks/json_schema_test_suite.py

@@ -7,7 +7,7 @@
 """
 from pyperf import Runner
 
-from jsonschema.tests._suite import Suite
+from _vendoring.jsonschema.tests._suite import Suite
 
 
 if __name__ == "__main__":

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

@@ -6,9 +6,9 @@
 import json
 import sys
 
-from jsonschema import __version__
-from jsonschema._reflect import namedAny
-from jsonschema.validators import validator_for
+from _vendoring.jsonschema import __version__
+from _vendoring.jsonschema._reflect import namedAny
+from _vendoring.jsonschema.validators import validator_for
 
 
 def _namedAnyWithDefault(name):

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

@@ -6,10 +6,10 @@
 import pprint
 import textwrap
 
-import attr
+import _vendoring.attr
 
-from jsonschema import _utils
-from jsonschema.compat import PY3, iteritems
+from _vendoring.jsonschema import _utils
+from _vendoring.jsonschema.compat import PY3, iteritems
 
 
 WEAK_MATCHES = frozenset(["anyOf", "oneOf"])
@@ -149,13 +149,13 @@ class SchemaError(_Error):
     _word_for_instance_in_error_message = "schema"
 
 
-@attr.s(hash=True)
+@_vendoring.attr.s(hash=True)
 class RefResolutionError(Exception):
     """
     A ref could not be resolved.
     """
 
-    _cause = attr.ib()
+    _cause = _vendoring.attr.ib()
 
     def __str__(self):
         return str(self._cause)