• If you don't clone a new instance of Spack, and only git pull into old instances, then each of those will continue to write into their own prefixes.

• If new instances are cloned but are configured to write outside of the default in ~, then old spack instances will continue to write into their own prefixes.

• If any new spack instance is cloned and writes into ~ (the new default in 1.2), then any old spack instance that updates to version 1.2 will start writing into ~ as well.

  • If you want to force an old instance to continue to write into the old default after pulling 1.2, then you will need to set config:install_tree:root to point to that location ($spack/opt/spack).
  • You can do this "ahead of time" as well: set config:install_tree:root before pulling 1.2.

Other data stored in $spack also moves out in 1.2:

• Environments, and you can restore old behavior with config:environments_root:$spack/var/spack/environments.

• Modules, and you can restore old behavior by setting modules:default:roots:{tcl,lmod} to $spack/share/spack/{modules,lmod}

• GPG keys

  • Default trusted keys for spack gpg init are stored in $spack/var/spack/gpg.
    If mixing old and new instances of spack spack gpg init --from=<spack-prefix>/var/spack/gpg if you placed any keys there (in other words, that directory is managed like any external store of GPG keys).
  • You can use the old storage location for keys by setting the SPACK_GNUPGHOME environment variable to <spack-prefix>/opt/spack/gpg.

1. Several changes to better handling compiler mixing during concretization:

   1. solver: penalize language virtuals for each use #51314
   2. solver: set preferences from input specs using %% #51383
   3. concretizer: option to disable compiler mixing between runtime deps #51135

2. Configuration scopes: fix severe ordering issue when -C and -e are used together #51461 - this fixes a bug with config ordering that we thought we fixed in 1.0. Environments are now always lower priority than -C scopes and -c config specified on the CLI.

3. config: define config scopes in configuration #51162: The $spack/etc/spack configuration scope inside the spack installation will be the highest priority scope, and you will be able to completely remove other configuration scopes (like ~/.spack) if you want to. To accommodate this, $spack/etc/spack will be higher priority than the user config scope (~/.spack) from 1.1 onwards. If you have configuration there that you want to be lower priority than the user scope, you can move it into $spack/etc/spack/site.

4. externals: Model as concrete specs and add dependency definitions #51118: Externals are treated differently by the concretizer, are more deterministic, and we now support defining dependencies among externals. This change is needed to properly match compilers between built packages and externals. Some behaviors, like auto-wiring external python extensions to a guessed python external, are deprecated and will need to be specified explicitly in packages.yaml in the future.

5. Enable concretization caching (redux) #50905: Concretization results are now cached by their inputs, so that we do not have to run clingo for every concretization call. This feature should be very robust, but we note it here in case you see issues. You should see typical concretizations take about half the time if they have been run before. Longer running concretizations should see even more benefit. This should be completely transparent, as we cache all inputs to the solve. If you see issues with concretization caching you can disable it in config with spack config set 'concretizer:concretization_cache:enable:false', or you can run spack clean -m to clear the cache.

[!WARNING]
You will have to add c, cxx, fortran, etc. dependencies to your packages (as introduced in #45217) for them to build with compilers. See additional breaking changes below.

1. Turn compilers into nodes #45189: In v1.0 compilers will be modeled as nodes. This PR tracks all the modifications that are necessary to change the DAG model in this sense.

   1. Parse % as ^ in specs  #49808: The meaning of the percent symbol % in spec strings will change, leading to a breaking change. In Spack v0.x it was a compiler property of a node, in Spack v1.0 it means "direct dependency" instead, and is similar to the caret ^ which means direct or transitive dependency. In Spack v0.x, pkg %gcc +foo parses the same as pkg +foo %gcc -- the +foo variant applies to pkg in either case. The breaking change in Spack v1.0 is that the variant +foo in pkg %gcc +foo now applies to gcc instead, since gcc is a normal package. This ensures we have the following symmetry:

      pkg +foo %dep +bar  # `pkg +foo` depends on `dep +bar` directly
      pkg +foo ^dep +bar  # `pkg +foo` depends on `dep +bar` directly or transitively
      

      In Spack v1.0.0.dev0 you will get warnings if you put +variant, @version, arch=, platform=, os=, target=, and /hash after the %compiler in a spec string.

      Eventually, (either in develop or in 1.0) this warning will turn into an error at concretization time, if +v is not a variant of pkg in specs like%pkg +v.

      On develop, you can use the spack style --spec-strings command to update package.py files, spack.yaml files, etc. You can run, e.g.:

      # dry run
      spack style --spec-strings $(git ls-files)  # if you have a git repo
      spack style --spec-strings spack.yaml  # environments
      
      # use --fix to perform the changes listed by the dry run
      spack style --fix --spec-strings $(git ls-files)
      spack style --fix --spec-strings spack.yaml

   2. After this PR spack compiler find will write by default in packages.yaml. The compilers.yaml configuration file is still read by Spack, if present, but is now deprecated. Future versions of Spack (possibly v1.2) will remove it.

   3. spack.spec.SpecBuildInterface: spack.repo dep #48984: removes support for spec["mpi"] if spec itself is openmpi / mpich that could provide mpi; from the Spec instance we don't have any parent it provides it to, hence it's a KeyError

   4. Spec.__getitem__: restrict to direct deps + transitive runtime deps #49016: with this change spec["pkg"] searches only direct dependencies and transitive link/run dependencies, ordered by depth. This avoids situations where we pick up unwanted deps of build/test deps. To reach those, you need to do spec["build_dep"]["pkg"] explicitly.

2. Toolchains: parse-time aliases for dependencies #50481: Spack now has a concept of a "toolchain". The toolchain is just an alias for common dependencies, flags, and other spec properties that you can attach to a node in a graph with %. This allows you to do with compiler dependencies what we used to do with compilers.yaml, and more. Toolchains are versatile and composable as they are simply aliases for regular specs. You can use them to represent mixed compiler combinations, compiler/MPI/numerical library groups, particular runtime libraries, and flags -- all to be applied together.

3. configuration: remove platform-specific scopes #50603: Platform config scopes are now opt-in. If you want to use subdirectories like darwin or linux in your scopes, you'll need to include them explicitly in an include.yaml or in your spack.yaml file, like so:

   include:
     - include: "${platform}"
       optional: true

4. binary_distribution: content addressable tarballs #48713: This changes the format of build caches to address a number of scaling and consistency issues with our current (aging) buildcache layout. The new build cache format is not backward compatible with the old format, but you can have a new build cache and an old build cache coexist together. After this is merged, binary mirrors that are not migrated will become unusable, as this change restructures how both spec files and compressed tarballs are stored within non-oci mirrors.

   • You will need to run spack buildcache migrate to migrate old build caches in place to the new format.

5. We will be splitting the builtin package repository out into its own git repository for v1.0. You can comment on the discussion here: Discussion: Move built-in packages to a separate repository #47480

   1. The builtin repo now lives in var/spack/repos/spack_repo/builtin instead of var/spack/repos/builtin
   2. The builtin repo was updated to package api v2.0. If you have custom package repositories that depend on builtin, you can upgrade those to package api v2.0 as well using the spack repo migrate command. It will deal with he following changes:
      1. If you used to import from spack.pkg.builtin in Python, you now need to import from spack_repo.builtin instead:

      from spack.pkg.builtin.my_pkg import MyPackage # OLD: no longer supported
      from spack_repo.builtin.packages.my_pkg.package import MyPackage  # NEW: spack_repo is a Python namespace package

      5. Directory names where normalized so they are valid Python modules

         • py-numpy/package.py -> py_numpy/package.py (hyphen is replaced by underscore)
         • 7zip/package.py -> _7zip/package.py (leading digits are now preceded by an underscore)
         • pass/package.py -> _pass/package.py (reserved keywords are preceded by an underscore)

      6. Move builders into builtin repo #50452: The module spack.package no longer exports the following symbols: AspellDictPackage, AutotoolsPackage, BundlePackage, CachedCMakePackage, cmake_cache_filepath, cmake_cache_option, cmake_cache_path, cmake_cache_string, CargoPackage, CMakePackage, generator, CompilerPackage, CudaPackage, Package, GNUMirrorPackage, GoPackage, IntelPackage, IntelOneApiLibraryPackageWithSdk, IntelOneApiLibraryPackage, IntelOneApiStaticLibraryList, IntelOneApiPackage, INTEL_MATH_LIBRARIES, LuaPackage, MakefilePackage, MavenPackage, MesonPackage, MSBuildPackage, NMakePackage, OctavePackage, PerlPackage, PythonExtension, PythonPackage, QMakePackage, RacketPackage, RPackage, ROCmPackage, RubyPackage, SConsPackage, SIPPackage, SourceforgePackage, SourcewarePackage, WafPackage, XorgPackage. For backward compatibility with old, custom repositories these symbols are implicitly defined in package.py and no action is required if your package has the typical from spack.package import * line. From package api v2.0 you need to explicitly import package classes, just like builders. Eventually this will look like from spack_repo.builtin.build_systems.cmake import CMakePackage, etc.

         These names will still work for old-style (v1.0) package repositories and not in v2.0 package API repos. v1.0 package repositories are deprecated in Spack v1.0, and will be removed in a future version, but this support will remain in place for at least a year so that you can continue to use old-style repos with Spack v1.0 and earlier versions simultaneously. Note: this means that the API stability promise in Spack v1.0 does not include old-style package repositories, so you should update as soon as you can.

6. Don't inject import statements in package recipes #47947: from spack.package import * (or more specific imports) will be necessary in packages. This also allows IDEs, code editors, and other tools to understand Spack packages better. The magic we have done since the early days of Spack was getting in the way for little benefit, and this change was also necessary to support Python 3.13.

7. Pin git sha to git ref based versions #44319: Before, Spack's Git reference based package versions (specifically tags and branches) were ambiguous i.e. two spec@develop installations from different commits could be treated as equivalent by the solver. This PR will cause spack to resolve branch and tags to specific commits using the spec@git.[commit sha]=develop syntax.

8. concretization: move spec concretization logic to spack.concretize #47971, spec.py: move lookup_hash and replace_hash to separate module #47978: Remove long-standing internal API methods Spec.concretize() and Spec.concretized(). They are immediately deprecated on develop and will be removed in the release. Use spack.concretize.concretize_one(spec) instead.

9. binary_distribution: stop relocating tarballs with relative rpaths #48488, binary_distribution.py: stop relocation old /bin/bash sbang shebang #48502: buildcache entries created with Spack 0.19 and older using spack buildcache create --rel will no longer be relocated upon install. These old binaries should continue to work, except when they are installed with different config:install_tree:projections compared to what they were built with. Similarly, buildcache entries created with Spack 0.15 and older that contain long shebang lines wrapped with sbang will no longer be relocated.

10. remove std_cmake_args, std_pip_args, std_meson_args #50462: the package.py globals std_cmake_args, std_pip_args, std_meson_args were removed. They were deprecated in Spack 0.23. Use CMakeBuilder.std_args(pkg), PythonPipBuilder.std_args(pkg) and MesonBuilder.std_args(pkg) instead.

11. Move external python glue logic into core #50605, Move python glue logic again #50616: If you were using update_external_dependencies() in your private packages, note that it is going away in 1.0 to get it out of the package API. It is instead being moved into the concretizer, where it can change in the future, when we have a better way to deal with dependencies of externals, without breaking the package API. We suspect that nobody was doing this, but it's technically a breaking change.

12. concretizer: make --force config and a common argument #48838: Two breaking command changes:

    • spack install no longer has a -f / --file option -- write spack install ./path/to/spec.json instead.
    • spack mirror create no longer has a short -f option -- use spack mirror create --file instead.

13. Developer Certificate of Origin (DCO): Spack is a Linux Foundation project and as part of this we started requiring DCO signoff on Spack commits in core. Packages do not (yet) require DCO. DCO was created for the Linux Kernel, and it's used by nearly all Linux Foundation projects. Basically what that means is that your commits need a signoff trailer like this at the end:

    Signed-off-by: Full Name <email>
    

    This is an attestation by you (not your company -- just you) that you have the right to contribute the code you're committing. The full text of the certificate is at developercertificate.org.

    In practice, it is fairly simple to comply with this. GitHub has support for automatically signing off commits made in the GitHub web UI, and git commits made on the command line just need an extra git commit --signoff or git commit -s argument. We will also be adding spackbot support in the future, so that you can @spackbot signoff if you forget. Once we do this we'll consider DCO for packages.

• Add depends_on([c,cxx,fortran]) #45217: Your packages can explicitly depend on the languages they require. Historically, Spack has considered C, C++, and Fortran compiler dependencies to be implicit. You will need to ensure that new packages add relevant languages as dependencies like this:

  depends_on("c", type="build")
  depends_on("cxx", type="build")
  depends_on("fortran", type="build")

  You do not have to add this to packages that don't need these languages, e.g., pure python packages.

  We have already auto-generated these dependencies for existing packages in #45217, based on the types of source files present in packages' source archives. We may have added too many or too few language dependencies, so please correct your packages as needed by submitting a pull request.

• Deprecate Cray platform, based on PE modules #43796: support for platform=cray is discontinued, and any mention of platform=cray has been removed from core and packages.

• concretize.lp: drop 0 weight of external providers #45025: Before, Spack was considering an external provider for a virtual as good as the preferred provider. After the change, the provider will keep its normal ranking. This means that if e.g. openmpi is the preferred mpi, and there's an entry for mpich in externals, then a new openmpi will be built - if building it is possible. To play well with externals, spack external find --not-buildable will mark virtuals as not buildable too, when a provider is detected.

• Remove the old concretizer #45215: The old concretizer has been removed from Spack, together with the associated config option. A warning is emitted if the option is present in user configuration, since it has now no effect. When clingo needs to be bootstrapped from sources, a JSON prototype is tweaked to get a correct concrete spec.

• Avoid best-effort expansion of stacks #40792: best-effort expansion of spec matrices has been removed. It was already not working for the new concretizer, and buggy with the old one. After Remove the old concretizer #45215 it didn't make sense to keep it.

• Deprecate config:install_missing_compilers #46237: The config:install_missing_compilers config option has been deprecated, and is a no-op when set in v0.23

• Remove deprecated config options #44061: The config options that have been deprecated in v0.21 are now removed in v0.23

• Compilers as dependencies: We are in the process of making compilers proper dependencies in Spack, and a number of changes in v0.22 will support that effort:

  • gcc-runtime: add separate package for gcc runtime libs #41104: Packages compiled with %gcc on Linux, macOS and FreeBSD now depend on a new package gcc-runtime, which contains a copy of the shared compiler runtime libraries. This fixes various issues: gcc runtime libraries can be installed and relocated when using a build cache, and when building minimal Spack-generated container images it is no longer necessary to install libgfortran, libgomp etc using the system package manager.
  • Add intel-oneapi-runtime, allow injecting virtual dependencies #42062: Packages compiled with %oneapi now depend on a new package intel-oneapi-runtime. The change is similar to gcc-runtime: add separate package for gcc runtime libs #41104, except now the runtimes can provide virtuals and compilers can inject dependencies on virtuals into compiled packages. This allows to model libraries soname compatibility and allows compilers like %oneapi to provide virtuals like sycl (that can also be provided by standalone libraries).
  • Improve hit-rate on buildcaches #43272: changes to the optimization criteria of the solver improved the hit-rate of buildcaches by a fair amount. Now the solver won't try to strictly match compilers or targets of reused specs, but has more relaxed compatibility rules. To get back the previous strict behavior users could write proper requirements, imposing the same compiler or target to all nodes. Also, to avoid reusing broken packages, Spack will discard all the %gcc and %oneapi specs that don't have the corresponding runtime as a dependency.
  • Allow reusing specs built with compilers not in config #43539: allows reusing specs built with compilers that are not in the local configuration. This is now possible, since specs will bring in their runtime. This will improve binary reuse of buildcaches, and will help with distro updates that e.g. bump the compiler version.
  • libc runtime #43190: binary compatibility on linux is now based on libc, instead of on the os tag. For each linux machine, allowed libcs are detected from the available compilers and used as an implicit external spec. Binaries with a libc having the same name and a version lesser or equal than a detected libc are considered compatible with it. Nothing changes for macOS or Windows.
  • External package detection for compilers #43464: each package that can provide a compiler is now detectable using spack external find. External packages defining compiler paths are effectively used as compilers, and spack external find -t compiler can be used as a substitute for spack compiler find.

• Improve parsing of quoted flags and variants in specs #41529: We are making some breaking changes to how Spack parses specs on the CLI in order to respect shell quoting instead of trying to fight it. If you had to write something like this on the command line (ugh):

  spack install zlib cflags=\"-O2 -g\"
  

  That will now result in an error, but you can now write what you probably expected to work in the first place:

  spack install zlib cflags="-O2 -g"
  

  Quoted can also now include special characters, so you can supply flags like:

  spack intall zlib ldflags='-Wl,-rpath=$ORIGIN/_libs'
  

  To reduce ambiguity in parsing, we now require that you not put spaces around = and == when for flags or variants.
  So, this will now result in an error where it wouldn't have before:

  spack install zlib cflags = "-O2 -g"
  

• python: always use a venv #40773: Spack has unique requirements for Python because it a) installs every package in its own independent directory and b) allows users to register external python installations that may contain their own installed packages. Some distributions like Ubuntu and Debian even change the system Python's sysconfig in ways that change the installation layout of Python packages when they are installed (e.g. with the addition of a /local prefix on Debian or Ubuntu). To isolate Spack from these and other issues, we now insert a small python-venv package in between python and packages that need to install Python code. This resolves a large number of issues we've had with Python installations.

• concretizer: update reuse: default to True #41302: We made a mistake when we set the default reuse policy to --reuse-deps instead of --reuse - we're changing it back for reasons outlined in this PR. You will need to use --reuse-deps if you want the old behavior.

• Only reuse externals when configured #41707: This ensures that external entries that make it into the database are only reused if they represent an external still configured in packages.yaml. This will ensure that changes to the configured externals are reflected immediately, rather than requiring additional steps to ensure the artifacts are no longer in the database.

• binary_distribution.py: list parent dirs in binary tarball #41773: Build cache entries created with Spack 0.22 are (forward) incompatible with Spack 0.21.0 (they cause errors on install), but are compatible with Spack 0.21.1. This is due to a backwards compatible change to the structure of the tarballs.

• spack load: remove --only argument #42120: removed the --only argument, which was deprecated in v0.21

• zlib-api: use zlib-ng +compat by default #39358: Possibly high impact, probably not: switching from zlib to the much faster zlib-ng+compat as our default zlib-api provider. If you notice issues, please comment on the PR.
• Remove deprecated versions and packages #37895: Removal of a large number of deprecated versions and packages, especially python and geospatial packages.
• Forbid using env: as a top level environment attribute #38199: Using env: as a top-level attribute in environments was deprecated in v0.20, and is removed in this PR.
• Add virtual information on DAG edges #34821: The spec JSON format (and DB format) will be bumped, and older spack versions won't be able to read it if you've installed things with this change. Similarly, older Spack versions will not be able to use newer build caches (this has never been a guaranteed, but older versions could at least read newer caches).
• Separate concretization of build dependencies (coupled) #38447 and Make "minimal" the default duplicate strategy #39621: Now Spack can duplicate build dependencies, in cases where this is necessary (e.g. conflicting versions of cython or setuptools in a DAG)
• ASP: targets, compilers and providers soft-preferences are only global #31261: preferences for targets, compilers and providers are only global, preferences for versions are only local to packages.
• Change container labeling so that "latest" is the latest tag #40593: nightly Docker images from the develop branch will be tagged as :develop, while :latest is reserved for the latest release.

• Remove support for running with Python 2.7 #33063: Spack develop no longer runs on Python 2.7! It's been a long journey to get to this point, but we finally said goodbye.
• Python: drop EOL versions #33898: Spack will no longer build EOL versions of Python. We now only support building 3.7 and later.
• Refer to mirrors by name, path, or url #34891: spack buildcache create is migrating to use more flexible positional arguments, and use of --directory. --mirror-url, and --mirror-name is deprecated.
• Disable module generation by default #35564: tcl module file generation is turned off by default. Users should now turn it on explicitly:

  spack config add modules:default:enable:[tcl]
  

• simplify spack install behavior #35206: makes the behavior of spack install less "surprising", when an environment is active. This is not backward compatible for commands like spack install x y z or spack install --add x y z (though the previous behavior is hard to justify with some rationale).
• cmake build system: change default build type to "Release" #36679 modifies the default value of the build_type variant in CMakePackage from RelWithDebInfo to Release. This will provide both performance and space savings. The PR and linked issue include longer discussions of the trade-offs involved.
• Improve version, version range, and version list syntax and behavior #36273: the version syntax and semantic have been extended. Now an expression like @X.Y always represents a range @X.Y:X.Y, no matter the context in which it appears. The new syntax @=X.Y has been introduced to specify a single version. This change solves issues we had for a long time with selecting a specific version, but is backward incompatible in a few pathological cases.
• concretizer: don't change concrete environments without --force #37438: Spack will not change the previously concretized specs, when new specs are added to an environment already in use and Spack is asked to concretize it. To reconcretize as if there was no previous lockfile, users have to pass the --force flag explicitly to spack concretize.
• Stand-alone testing: Make recipe support and processing spack-/pytest-like #34236: the way to encode stand-alone tests has changed, and now it is more "pytest-like". Details are in the documentation. Using the old way of encoding tests is deprecated in v0.20 (but still supported with a warning). Support for running test encoded in the old way will be removed in v0.21.

• remove activate/deactivate support in favor of environments #29317: global activation/deactivation of extensions have been removed in favor of using environment views
• remove deprecated top-level module config #33828: the top level module configuration, already deprecated in v0.18, will be removed in v0.19
• remove deprecated concretization environment key #33774: the concretization key in Spack environment, already deprecated in v0.18, will be removed in v0.19
• Deprecate spack bootstrap trust/untrust #33600: the spack bootstrap trust/untrust commands are deprecated as of v0.19, in favor of spack bootstrap enable/disable
• Deprecate old YAML format for buildcaches #33707: the YAML format for buildcaches is deprecated as of v0.19 and support for it will be removed in v0.20
• "spack uninstall": don't modify env #33711: spack install in an environment will no longer add to the specs: list; you'll need to either use spack add <spec> or spack install --add <spec>. Similarly, spack uninstall will not remove specs from your environment's specs: list; you will need to use spack remove or spack uninstall --remove. This is to minimize the number of commands that modify spack.yaml, and to make it easier to install/uninstall specific specs from environments stored in repositories.
• Cray support: use linux platform for newer craype versions #29392: Spack will take advantage of new features in the CrayPE to treat Cray EX systems at newer versions like linux builds. This will reduce the likelihood of cray-specific bugs and reduce the maintenance burden going forward, and make package development for cray systems much simpler.
• Don't set LD_LIBRARY_PATH on package load #28354: spack load and spack-generated modules will no longer set LD_LIBRARY_PATH by default. You can get the old behavior in your environment or modules by running:

  spack config add modules:prefix_inspections:lib64:[LD_LIBRARY_PATH]
  spack config add modules:prefix_inspections:lib:[LD_LIBRARY_PATH]

• Deprecate Python 2 support #32615: Spack v.0.19 will be deprecating Python 2 support, and Python 2 support will be removed from Spack develop shortly after v0.19 is released.
• Enable/Disable Propagation for Compiler Flags & Variants #29761: Compiler flags will no longer propagate to dependencies by default (you will need cflags==-O3 instead of cflags=-O3)
• Format all of Spack with black #24718: This touches a lot of code and may conflict your PRs
• deprecate blacklist/whitelist in favor of include/exclude #31569: We're changing module configuration syntax slightly. You can use spack config update to automatically fix your configuration files.
• Allow packages with multiple build-systems (separate classes) #30738: The format for package recipes will change to support packages that change build-systems across versions or platforms. In the future people will need to code more than one class in a package.py. Backward compatibility with the previous style is kept as much as possible.

• Reuse by default in Spack #30396: We will be making --reuse the default concretizer behavior. This will be configurable so you can revert back using Add a top-level concretizer config scope and --fresh option #28468.
• Switch to full hash everywhere #28504: After --reuse is default, we will be switching to a "full hash" as the default package id in Spack. Spack has long used a coarser package hash that it probably should, in order to prevent redundant rebuilds. Specifically, we omit build dependencies, the hash of package.py, and the hashes of resources (tarballs, etc.) from our build identifiers. This was mainly to prevent every update of cmake or other build tools from triggering a rebuild of the full stack. With --reuse as the default, we don't have this concern any more, and we will prioritize detailed provenance for package builds. The full hash will provide this and will also avoid hash collisions that we currently see in CI.
• Allow for multiple dependencies/dependents from the same package #28673: This PR allows a given spec to depend on multiple instances of the same package, differentiated by dependency type; recording the dependency type will change the underlying storage representation
• PythonPackage: install packages with pip #27798: This PR completely changes how we install Python packages to run pip install instead of python setup.py install. It also improves bootstrapping of frontend tools (pip/build/installer) and backend tools (setuptools/flit/poetry).
• Revert "Deprecate Python 2 installations" #28411: We got some volunteers and will be reverting the change below. Spack will continue to support Python 2.7 and 3.5 for reproducibility.
• Deprecate Python 2 installations #28003: This PR deprecates versions of Python that have reached EOL (Python 2.7-3.5) and packages that require them. Note that this PR does not affect which versions of Python can be used to run Spack, it only affects which versions of Python Spack can install.

• specs: move to new spec.json format with build provenance #22845: This PR changes the spec.yaml format that Spack uses for hashes to spec.json. We're doing this for performance -- YAML is too slow for large operations, like reindexing the Spack database or creating indexes for large build caches. We expect this to speed up Spack in many ways, but it will cause the hashing algorithm to change.
• Make clingo the default solver #25502: This PR makes clingo the default solver, in preparation for 0.17.0. You may see different concretizations for some packages, and the new concretizer will need to be bootstrapped (see https://spack.io/changes-spack-v017/). You can switch back by setting concretizer: original in config.yaml, but note that the original concretizer will be deprecated in 0.17 and removed in a later version.
• Remove support for Python 2.6 #27256: Python 2.6 was deprecated in Spack v0.17.0 and support has been removed in develop -- it will not be supported in v0.18.