v1.2.2 (2026-07-20)

Bug fixes

• Concretization cache:
  • Fix accidental exponential complexity issue in spec hash, and disable for spliced specs (#52665)
  • Fix serialization issues with abstract input spec (#52714, #52716)
  • Prune cache only after write (#52715)
  • Reduce excessive syscalls (#52721)
• Make spack --disable-locks apply to all file system locks used by Spack (#52270)
• Fix a patch file lookup issue when using multiple package repositories (#52675)
• Fix a few issues with spack isolate --self (#52725)
• Fix an issue where repositories did not raise InvalidNamespaceError correctly (#52689)

v1.2.1 (2026-07-06)

Bug fixes

• Installer bugfixes:
  • Fix a hang of the new installer when running under forkserver (#52621)
  • Sanitize the computed build log filename (#52660)
  • Allow local installs for packages missing in upstream (#52630)
  • Restore working_dir in build subprocess (#52576)
• Solver bugfixes:
  • Restore performance on macOS (#52604, #52603)
  • Fix the solver heuristic for build_set_id (#52634)
  • Drop noisy debug message (#52640)
• Fix environment view regeneration when using multiple overlayfs layers (#52594)
• Fix spack cd -e and other dash-prefixed args in fish (#52586)
• Fix spack location with -v / --view and no environment active (#52587)
• Allow multiple py-setuptools-scm specs in a dependency graph (#52595)
• Fix overly strict file permission issue when updating config files (#52653)
• Fix libc detection when -Wl,--dynamic-linker is passed with two dashes (#52626)
• Fix config warning messages when there's no associated source file (#52638)
• Handle empty list of URLs when generating BOM (#52585)
• Fix temporary dir logic sometimes hitting a Windows code path on POSIX platforms (#52600)

v1.2.0 (2026-06-21)

v1.2.0 is a major feature release. The main changes you'll notice are the new, parallel installer and the many performance improvements we've added. There are also usability features like concretization groups, and security features like experimental build sandboxing and SBOM generation.

Major new features

1. New installer

   Spack v1.2.0 defaults to the new installer, which is a completely rewritten package installer designed for better performance and improved user experience. This was an experimental feature in v1.1.0. The new installer takes advantage of much more build parallelism by scheduling multiple package builds concurrently and sharing their work dynamically using a jobserver.

   The most visible change is the new interactive Terminal User Interface (TUI). It shows an overview of all active, concurrently running builds, and lets you follow logs of specific builds by pressing v, n (next), or p (previous).

   The new installer is a single-threaded, event-driven build scheduler using non-blocking I/O. A single spack install process exploits DAG-level parallelism by scheduling independent package builds concurrently. All concurrent builds share a jobserver (a POSIX pipe) set up by Spack to manage composable parallelism, which allows builds to dynamically share work up to a job limit. For example, while one package is restricted to a single-threaded configure step, other, more parallel builds can claim the idle jobs. The new installer also optimizes database writes, which is noticeable when installing many packages from a binary cache.

   See the docs and this talk from HPSFCon2026 for more details.

2. Concretization Groups

   A single environment can now have named groups of specs with their own local concretization preferences and dependencies. You can use this to control concretization order, e.g. if you need to bootstrap a compiler to build certain applications:

   spack:
     specs:
     - group: compiler
       specs:
       - gcc@15.2
   
     - group: apps
       needs: [compiler]
       specs:
       - hdf5 %gcc@15.2
       - libtree %gcc@15.2

   Or, you can use it to provide different targets, variants, or other preferences for
   specific groups:

   spack:
     specs:
     - group: apps-x86_64_v3
       specs:
       - gromacs
       - quantum-espresso
       override:
         packages:
           all:
             prefer:
             - target=x86_64_v3
   
     - group: apps-x86_64_v4
       specs:
       - gromacs
       - quantum-espresso
       override:
         packages:
           all:
             prefer:
             - target=x86_64_v4

   Each group is concretized independently, and concrete specs from dependency groups are included in each group's solve. Previously, workflows like these required multiple environments. See the environment docs and #51891, #52244, #52489 for more information.

3. Concretization Caching

   You should notice a significant speedup when running the same concretization multiple times. Spack now caches concretization results and can detect when a solve will be the same. For example, if you run:

   spack spec hdf5
   spack install hdf5

   Spack now only has to concretize hdf5 one time. Concretization caching was introduced as an experimental feature in v1.1.0, and it is now enabled by default.

4. Generate SBOMs during package installation

   Software Bills of Materials (SBOMs) are standardized files that list the components, dependencies, and licenses included in an installation. They are gaining traction in the security world, as they can be consumed and analyzed by tools to detect CVEs and other software compliance issues.

   Spack now automatically generates SPDX 2.3 SBOMs at install time. The files can be found in the $prefix/.spack/sbom directory, where $prefix is a package's installation prefix. Spack SBOMs currently contain the NTIA Minimum Elements (supplier, component name, version, unique identifiers, and dependency relationships) where the information is available from Spack metadata.

   More in the docs and #51760.

5. New command: spack isolate

   spack isolate provides a mechanism for isolating a single Spack instance from ~/.spack. It modifies the current Spack instance by setting the user configuration scope to use a custom path, and it uses an isolate configuration scope to move caches and stages that usually default to ~/.spack to the custom location, as well.

   There are three ways to use it:

   1. spack isolate --self will modify Spack to only write to its own prefix (i.e., the $spack directory);
   2. spack isolate --path PATH will modify Spack to only write to a custom PATH of your choosing; and
   3. spack isolate --undo will revert Spack's internal config and undo the isolation.

   See
   the documentation for more.

Experimental sandboxing

Spack v1.2 adds experimental support for
Linux Landlock as a sandbox. Linux Landlock is a relatively new kernel feature (5.13+) that allows a process to self-restrict its file system read/write/execute permissions further. It is a very lightweight syscall that does not require root privileges or support for unprivileged namespaces (as is typical for container runtimes).

Landlock is a good fit for Spack, as it allows us to deny write access to all directories except the build stage and install prefix, while giving read/execute permissions only to the build stage and dependency prefixes. Users can specify further executables, libraries, and directories to be readable, writeable or executable. Looking forward (Spack v1.3), we aim to make the sandbox default to enable fully reproducible, isolated, unprivileged builds.

See #52334 for more details.

Deprecations and potentially breaking changes

• GPG commands would previously silently trust keys by default. They now require a --yes-to-all argument, and by default they will interactively prompt for trust (#52430)
• deprecate spack gpg verify and spack gpg sign as unnecessary (#52431)
• spack install: deprecate --dont-restage (#51604)
• main.py: deprecate --pdb, drop SIGINT handler (#52281)
• main.py: deprecate --profile flags (#52301)
• spack compiler: remove deprecated --mixed-toolchain option (#51726)
• include_concrete: is now deprecated in favor of include: [spack.lock] (#51900)

Other notable changes

Core development

• spack style now uses ruff instead of flake8, isort, and black (#52156)
• we now provide python 3.14 binaries for bootstrapping (#51580)

Improved error messages

• solver: error out early for non-existing and deprecated versions (#51555)
• solver: improve version constraint error messages (#51926)
• solver: remove internal errors in the solver (#51642)

Performance improvements

• views: collapse unique subtrees in symlink case (#52135)
• solver: simplify encoding of versions (#51591)
• solver: manually optimize trigger_node projections (#51605)
• solver: optimize the encoding of the model (#51612)
• solver: reduce grounding size of satisfied/2 facts (#51625)
• solver: avoid repeated external "parsing" (#51653)
• solver: improve the number of cache hits for triggers and effects (#51863)
• solver: improve version encoding (#51872)
• solver: simplify and improve encoding of variants (#51988)
• asp.py: do not sort pkg.dependencies and versions (#51632)
• asp.py: move Spec.str out of loop (#51629)
• Spec.format: speed up common case (#51630)
• Avoid expensive module level code (#51650)
• Git Fetch: Optimize clone for single commits (#51577)
• ctest_log_parser.py: faster and sequential (#52249)
• setup-env.sh: speed up when no module command (#52245)

Concretizer improvements

• solver now supports clingo v6 (#52411)
• solver: prefer best compiler above one with no penalty on variants (take 2) (#52109)
• solver: match glibc constraints by hash (#51559)
• solver: exclude externals from deprecation penalties (#51764)
• solver: deterministic concretization with non-default variant values (#51780)
• solver: fix variant penalty for variants defined with a validator function (#51844)
• solver: account for variant penalties correctly when only one of multiple values is "set" (#51847)
• solver: requiring at least a subset of default values of a multivalued variant should not influence concretization (#51851)
• solver: don't give a penalty for compiler reuse on compilers (#51744)

UI and commands

• Include/exclude specs from binary caches (mirrors) (#52371)
• spack config: add --group option (#52025)
• add command spack location --view (#52177)
• log parser: tail -n like support (#52279)
• spack repo remove: allow removing from unspecified scope (#51563)
• Add --profile-file filename option to save cProfile stats. (#51543)
• spack repo: add show-version-updates command (#52170)
• spack repo list: machine readable output with --json (#51950)
• Allow env variables in package_attributes (#52450)
• Show [b] in spack concretize and other commands when a package is not installed
  but is available from a binary cache (#52493)

Notable bugfixes

• bugfix: don't stop early when other spack process is installing (#51539)
• macos: allow installing binaries from older os (#52390)
• solver: disable compiler mixing per-language (#51796)
• solv...

v1.0.4 (2026-02-23)

v1.0.4 (2026-02-23)

Bug fixes

• Concretizer bugfixes:
  • solver: remove a special case for provider weighting #51347
  • solver: improve timeout handling and add Ctrl-C interrupt safety #51341
  • solver: simplify interrupt/timeout logic #51349
• Repo management bugfixes:
  • repo.py: support rhel 7 #51617
  • repo.py: fix checking out commits #51695
  • git: pull_checkout_branch RHEL7 git 1.8.3.1 fix #51779
  • git: fix locking issue in pull_checkout_branch #51854
  • spack repo remove: allow removing from unspecified scope #51563
• build_environment.py: Prevent deadlock on install process join #51429
• Fix typo in untrack_env #51554
• audit.py: fix re.sub(..., N) positional count arg #51735

Enhancements

• Support Macos Tahoe (#51373, #51394, #51479)
• Support for Python 3.14, except for t-strings (#51686, #51687, #51688, #51697, #51663)
• spack info: show conditional dependencies and licenses; allow filtering #51137
• Spack fetch less likely to fail due to AI download protections #51496
• config: relax concurrent_packages to minimum 0 #51840
  • This avoids forward-incompatibility with Spack v1.2
• Documentation improvements (#51315, #51640)

v1.1.1 (2026-01-14)

Usability and performance enhancements

• solver: do a precheck for non-existing and deprecated versions #51555
• improvements to solver performance (PRs #51591, #51605, #51612, #51625)
• python 3.14 support (PRs #51686, #51687, #51688, #51689, #51663)
• display when conditions with dependencies in spack info #51588
• spack repo remove: allow removing from unspecified scope #51563
• spack compiler info: show non-external compilers too #51718

Improvements to the experimental new installer

• support forkserver #51788 (for python 3.14 support)
• support --dirty, --keep-stage, and skip patch arguments #51558
• implement --use-buildcache, --cache-only, --use-cache and --only arguments #51593
• implement overwrite, keep_prefix #51622
• implement --dont-restage #51623
• fix logging #51787

Bugfixes

• repo.py: support rhel 7 #51617
• solver: match glibc constraints by hash #51559
• buildache list: list the component prefix not the root #51635
• solver: fix issue with conditional language dependencies #51692
• repo.py: fix checking out commits #51695
• spec parser: ensure toolchains are expanded to different objects #51731
• RHEL7 git 1.8.3.1 fix #51779
• RewireTask.complete: return value from _process_binary_cache_tarball #51825

Documentation

• docs: fix default projections setting discrepancy #51640

v1.1.0 (2025-11-14)

v1.1.0 features major improvements to compiler handling and configuration management, a significant refactoring of externals, and exciting new experimental features like a console UI for parallel installations and concretization caching.

Major new features

1. Enhanced Compiler Control and Unmixing

   • Compiler unmixing (#51135)
   • Propagated compiler preferences (#51383)

   In Spack v1.0, support for compilers as nodes made it much easier to mix compilers for the same language on different packages in a Spec. This increased flexibility, but did not offer options to constrain compiler selection when needed.

   • #51135 introduces the concretizer:compiler_mixing config option. When disabled, all specs in the "root unification set" (root specs and their transitive link/run deps) will be assigned a single compiler for each language. You can also specify a list of packages to be excepted from the restriction.

   • #51383 introduces the %% sigil in the spec syntax. While % specifies a direct dependency for a single node, %% specifies a dependency for that node and a preference for its transitive link/run dependencies (at the same priority as the prefer key in packages.yaml config).

2. Customizable configuration (#51162)

   All configuration now stems from $spack/etc/spack and $spack/etc/spack/defaults, so the owner of a Spack instance can have full control over what configuration scopes exist.

   • Scopes included in configuration can be named, and the builtin site, user, system, etc. scopes are now defined in configuration rather than hard-coded.
   • $spack/etc/spack/defaults is the lowest priority.
   • $spack/etc/spack includes the other scopes at lower precedence than itself.
   • You can override with any scopes except the defaults with include::. e.g., include::[] in an environment allows you to ignore everything but defaults entirely.

   Here is $spack/etc/spack/include.yaml:

   include:
     # user configuration scope
     - name: "user"
       path: "~/.spack"
       optional: true
       when: '"SPACK_DISABLE_LOCAL_CONFIG" not in env'
   
     # site configuration scope
     - name: "site"
       path: "$spack/etc/spack/site"
       optional: true
   
     # system configuration scope
     - name: "system"
       path: "/etc/spack"
       optional: true
       when: '"SPACK_DISABLE_LOCAL_CONFIG" not in env'

   NOTE: This change inverts the priority order of configuration in $spack/etc/spack and ~/.spack.

   See the configuration docs and
   include docs for
   more information.

3. Git includes (#51191)

   Configuration files can now be included directly from a remote Git repository. This allows for easier sharing and versioning of complex configurations across teams or projects. These entries accept the same syntax as remote repository configuration, and can likewise be conditional with when:.

   include:
   - git: https://github.com/spack/spack-configs
     branch: main
     when: os == "centos7"
     paths:
     - USC/config/config.yaml
     - USC/config/packages.yaml

   See the docs for details.

4. Externals Can Now Have Dependencies (#51118)

   Externals are treated as concrete specs, so there is a 1:1 mapping between an entry in packages.yaml and any installed external spec (for a fixed repository).

   Their YAML specification has been extended to allow modeling dependencies of external specs. This might be quite useful to better capture e.g. ROCm installations that are already installed on a given system, or in similar cases.

   To be backward compatible with external specs specifying a compiler, for instance mpich %gcc@9, Spack will match the compiler specification to an existing external. It will fail when the specification is ambiguous, or if it does not match any other externals.

   See the documentation for more details.

Experimental Features

5. New installer UI (experimental, see #51434)

   New, experimental console UI for the Spack installer that allows:

   • Spack to show progress on multiple parallel processes concurrently;
   • Users to view logs for different installations independently; and
   • Spack to share a jobserver among multiple parallel builds.

   

   Usage:

   • Run this to enable by default (and persist across runs):

     spack config add config:installer:new
     

     or use:

     spack -c config:installer:new install ...
     

     to try one run with the new UI.
   • The -j flag in spack install -j <N> ... is all you need, it will build packages in parallel. There is no need to set -p; the installer spawns as many builds as it can and shares work by default.
   • Use n for next logs and p/N for previous logs
   • Use v to toggle between logs and overview
   • Use q or Esc to go from logs back to overview.
   • Use / to enter search mode: filters the overview as you type; press Enter to follow logs or Esc to exit search mode.

   [!WARNING]
   This feature is experimental because it is not feature-complete to match the existing installer. See the issue #51515 for a list of features that are not completed. Particularly note that the new installer locks the entire database, and other spack instances will not install concurrently while it is running.

6. Concretization Caching (experimental, see #50905, #51448)

   Spack can cache concretization outputs for performance. With caching, Spack will still set up the concretization problem, but it can look up the solve result and avoid long solve times. This feature is currently off by default, but you can enable it with:

   spack config add concretizer:concretization_cache:enable:true
   

   [!WARNING]
   Currently there is a bug that the cache will return results that do not properly reflect changes in the package_hash (that is, changes in the package.py source code). We will enable caching by default in a future release, when this bug is fixed.

Potentially breaking changes

• Configurable configuration changes the precedence of the site scope.
  • The spack scope (in /etc/spack within the Spack installation) is now the highest precedence scope
  • The site scope is now lower precedence than spack and user.
  • If you previously had configuration files in in $spack/etc/spack, they will take precedence over configuration in ~/.spack. If you do not want that, move them to $spack/etc/spack/site.
  • See #51162 for details.
• Fixed a bug with command-line and environment scope ordering. The environment scope could previously override custom command-line scopes. Now, the active environment is always lower precedence than any configuration scopes provided on the command line. (#51461)

Other notable improvements

Improved error messages

• solver: catch invalid dependencies during concretization (#51176)
• improved errors for requirements (#45800)

Performance Improvements

• spack mirror create --all now runs in parallel (#50901)
• spack develop: fast automatic reconcretization (#51140)
• Don't spawn a process for --fake installs (#51491)
• Use gethostname instead of getfqdn (#51481)
• Check for commit variant only if not developing (#51507)
• Concretization performance improvements (#51160, #51152, #51416)
• spack diff: fix performance bug (#51270)

Concretizer improvements

• concretizer: fix direct dep w/ virtuals issue (#51037)
• solver: reduce items in edge optimizations (#51503)

UI and Commands

• Managed environments can now be organized into folders (#50994)
• spack info shows full info about conditional dependencies and can filter by spec. (#51137)
• spack help is now reorganized and has color sections (#51484)
• spack clean --all means all (no exception for bootstrap cache) (#50984)
• --variants-by-name no longer used (#51450)
• spack env create: allow creation from env or env dir (#51433)

Notable Bugfixes

• mirror: clean up stage when retrying (#43519)
• Many smaller concretization fixes (#51361, #51355, #51341, #51347, #51282, #51190, #51226, #51065, #51064, #51074)
• Bugfix for failed multi-node parallel installations (#50933)

Spack community stats

• 1,681 commits
• 8,611 packages in the 2025.11.0 release, 112 new since 2025.07.0
• 276 people contributed to this release
• 265 committers to packages
• 31 committers to core

See the 2025.11.0 release of spack-packages for more details.

v1.0.2 (2025-09-11)

Bug Fixes

• spack config edit can now open malformed YAML files. (#51088)
• spack edit -b supports specifying the repository path or its namespace. (#51084)
• spack repo list escapes the color code for paths that contain @g. (#51178)
• Fixed various issues on the solver:
  • Improved the error message when an invalid dependency is specified in the input. (#51176)
  • Build the preferred compiler with itself by default. (#51201)
  • Fixed a performance regression when using unify:when_possible. (#51226)
  • Fixed an issue with strong preferences, when provider details are given. (#51263)
  • Fixed an issue when specifying flags on a package that appears multiple times in the DAG. (#51218)
• Fixed a regression for zsh in spack env activate --prompt. (#51258)
• Fix a few cases where the when context manager was not dealing with direct dependencies correctly. (#51259)
• Various fixes to string representations of specs. (#51207)

Enhancements

• Various improvements to the documentation. (#51145, #51151, #51147, #51181, #51172, #51188, #51195)
• Greatly improve the performance of spack diff. (#51270)
• spack solve highlights optimization weights in a more intuitive way. (#51198)

v1.0.1 (2025-08-11)

Bug Fixes

• Ensure forward compatibility of package hashing with the upcoming Python 3.14 release. (#51042)
• The spack diff command now shows differences in runtime dependencies (e.g., gcc-runtime, glibc), which were previously hidden. (#51076)
• Fix a regression where the solver would mishandle a compiler that was required as both a build and a link dependency. (#51074)
• Resolved issues with selecting external packages that have a specific compiler specified. (#51064)
• Fix a bug where the concretizer would compute solution scores incorrectly when the package does not depend on a compiler. (#51037)
• The solver now correctly evaluates and respects package requirements that specify a hash. (#51065)
• Fix an issue where sparse checkouts for different packages could overwrite each other in a source cache or mirror. (#51080)
• Prevent spack repo add from overwriting the default branch when initially cloning a repository. (#51105)
• Add exception handling for bad URLs when fetching git provenance information. (#51022)
• Spack no longer conflates git warning messages with command output. (#51045)
• Fix an issue with non-path-based package repositories in environments. (#51055)
• Spack now validates the terminal size and will fall back to LINES and COLUMNS environment variables if detection fails. (#51090)
• Fix an issue where the package's fetcher was not being set correctly. (#51108)
• Ensure spack tutorial clones Spack v1.0 instead of v0.23. (#51091)

Enhancements

• Various improvements to the documentation (#51014, #51033, #51039, #51049, #51066, #51073, #51079, #51082, #51083, #51086, #51126, #51131, #51132, #51025)

v1.0.0 (2025-07-20)

v1.0.0 is a major feature release and a significant milestone. It introduces compiler dependencies, a foundational change that has been in development for almost seven years, and the project's first stable package API.

If you are interested in more information, you can find more details on the road to v1.0, as well as its features, in talks from the 2025 Spack User Meeting. For example:

• State of the Spack Community
• Spack v1.0 overview

Introducing some of these features required us to make breaking changes. In most cases, we've also provided tools (in the form of Spack commands) that you can use to automatically migrate your packages and configuration.

Overview

• Overview
• Stable Package API
  • Separate Package Repository
  • Updating and Pinning Packages
  • Breaking changes related to package repositories
  • Migrating to the new package API
• Compiler dependencies
  • Compiler configuration
  • Languages are virtual dependencies
  • The meaning of % has changed
  • Virtual assignment syntax
  • Toolchains
  • Ordering of variants and compilers now matters
• Additional Major Features
  • Concurrent Package Builds
  • Content-addressed build caches
  • Better provenance and mirroring for git
  • Environment variables in environments
  • Better include functionality
• New commands and options
• Notable refactors
• Documentation
• Notable Bugfixes
• Additional deprecations, removals, and breaking changes
• Spack community stats

Stable Package API

In Spack v1.0, the package repository is separate from the Spack tool, giving you more control over the versioning of package recipes. There is also a stable Package API that is versioned separately from Spack.

This release of Spack supports package API from v1.0 up to v2.2. The older v1.0 package API is deprecated and may be removed in a future release, but we are guaranteeing that any Spack v1.x release will be backward compatible with Package API v.2.x -- i.e., it can execute code from the packages in this Spack release.

See the Package API Documentation for full details
on package versioning and compatibility. The high level details are:

1. The spack.package Python module defines the Package API;
2. The Package API minor version is incremented when new functions or classes are exported from spack.package; and
3. The major version is incremented when functions or classes are removed or have breaking changes to their signatures (a rare occurrence).

This independent versioning allows package authors to utilize new Spack features without waiting for a new Spack release. Older Spack packages (API v1.0) may import code from outside of spack.package, e.g., from spack.* or llnl.util.*. This is deprecated and not included in the API guarantee. We will remove support for these packages in a future Spack release.

Separate Package Repository

The Spack builtin package repository no longer lives in the Spack git repository. You can find it here:

• https://github.com/spack/spack-packages

Spack clones the package repository automatically when you first run, so you do not have to manage this manually. By default, Spack version v1.0 uses the v2025.07 release of spack-packages. You can find out more about it by looking at the package releases.

Downloaded package repos are stored by default within ~/.spack, but the fetch destination can be configured. (#50650). If you want your package repository to live somewhere else, run, e.g.:

spack repo set --destination ~/spack-packages builtin

You can also configure your own package repositories to be fetched automatically from git urls, just as you can with builtin. See the repository configuration docs for details.

Updating and Pinning Packages

You can tell Spack to update the core package repository from a branch. For example, on develop or on a release, you can run commands like:

# pull the latest packages
spack repo update

or

# check out a specific commit of the spack-packages repo
spack repo update --commit 2bf4ab9585c8d483cc8581d65912703d3f020393 builtin

which will set up your configuration like this:

repos:
  builtin:
    git: "https://github.com/spack/spack-packages.git"
    commit: 2bf4ab9585c8d483cc8581d65912703d3f020393

You can use this within an environment to pin a specific version of its package files. See the repository configuration docs for more details (#50868, #50997, #51021).

Breaking changes related to package repositories

1. The builtin repo now lives in var/spack/repos/spack_repo/builtin instead of var/spack/repos/builtin, and it has a new layout, which you can learn about in the repo docs.

2. The module spack.package no longer exports the following symbols, mostly related to build systems:
   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

   These are now part of the builtin package repository, not part of core spack or its package API. When using repositories with package API v2.0 and higher, you must explicitly import these package classes from the appropriate module in spack_repo.builtin.build_systems (see #50452 for more).

   e.g., for CMakePackage, you would write:

   from spack_repo.builtin.build_systems.cmake import CMakePackage

   Note that GenericBuilder and Package are part of the core package API. They are currently re-exported from
   spack_repo.builtin.build_systems.generic for backward compatibility but may be removed from the package repo. You should prefer to import them from spack.package.

   The original names will still work for old-style (v1.0) package repositories but not in v2.0 package repositories. Note that this means that the API stability promise does not include old-style package repositories. They are deprecated and will be removed in a future version. So, you should update as soon as you can.

3. Package directory names within v2.0 repositories are now valid Python modules

   Old	New	Description
   py-numpy/package.py	py_numpy/package.py	hyphen is replaced by underscore.
   7zip/package.py	_7zip/package.py	leading digits now preceded by _
   pass/package.py	_pass/package.py	Python reserved words preceded by _

4. Spack has historically injected import statements into package recipes, so there was no need to use from spack.package import * (though we have included it in builtin packages for years. from spack.package import * (or more specific imports) will be necessary in packages. The magic we added in the early days of Spack was causing IDEs, code editors, and other tools not to be able to understand Spack packages. Now they use standard Python import semantics and should be compatible with modern Python tooling. This change was also necessary to support Python 3.13. (see #47947 for more details).

Migrating to the new package API

Support will remain in place for the old repository layout for at least a year, so that you can continue to use old-style repos in conjunction with earlier versions. If you have custom repositories that need to migrate to the new layout, you can upgrade them to package API v2.x by running:

spack repo migrate

This will make the following changes to your repository:

1. If you used to import from spack.pkg.builtin in Python, you now need to import from spack_repo.builtin instead:

   # OLD: no longer supported
   from spack.pkg.built...

v1.0.0-alpha.4 (2025-03-01)

Caution

This alpha release is outdated. Use develop to try compilers as dependencies, as there are ongoing bug fixes.

See v1.0.0-alpha.1 for a general description of the changes in the software model. Since the last alpha release, the following changes have been implemented:

• Better handling of legacy compilers.yaml: entries in compilers.yaml will be "converted" to entries in packages.yaml, when Spack tries to initialize automatically the compiler configuration, and only if no other compiler is present.
• Better handling of outdated database formats: now Spack will error out when using an outdated database format. The error message shows users the options available: either reindexing and updating the format (and lose compatibility with previous versions of Spack), or point the store to a new location.
• Externals can have compiler tokens: compiler tokens, like %gcc, are accepted in external specs, even though the externals have no dependencies. The information is used to decide whether to use the external, or not, during concretization.
• Compilers from store or buildcache: compilers can now be used directly from the local store (always), or from the buildcache (when reuse is active). This opens the possibility to register a mirror with a compiler and let Spack use said compiler in concretization.
• Compiler support: fixed support for using vendor compilers (Cray, NVIDIA, etc.)
• Default configuration: set default requirements for macOS. Spack ships with apple-clang required by default for C and C++, and gcc required by default for Fortran.

Many package recipes have been fixed, and pipelines are building correctly.