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.

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)

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

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.

Bugfixes

• Continue to mark non-roots as implicitly installed on partial env installs (#47183)

Notes

• v0.22.4 is skipped to do an error in the release process

Bugfixes

• Fix a correctness issue of ArchSpec.intersects (#48741)
• Make extra_attributes order independent in Spec hashing (#48615, #48854)
• Fix issue where system proxy settings were not respected in OCI build caches (#48783)
• Fix an issue where the --test concretizer flag was not forwarded correctly (#48417)
• Fix an issue where codesign and install_name_tool would not preserve hardlinks on Darwin (#47808)
• Fix an issue on Darwin where codesign would run on unmodified binaries (#48568)
• Patch configure scripts generated with libtool < 2.5.4, to avoid redundant flags when creating shared libraries on Darwin (#48671)
• Fix issue related to mirror URL paths on Windows (#47898)
• Ensure proper UTF-8 encoding/decoding in logging (#48005)
• Fix issues related to filter_file (#48038, #48108)
• Fix an issue related to creating bootstrap source mirrors (#48235)
• Fix an issue where command line config arguments were not always top level (#48255)
• Fix an incorrect typehint of concretized() (#48504)
• Improve mention of next Spack version in warning (#47887)
• Tests: fix forward compatibility with Python 3.13 (#48209)
• Docs: encourage use of --oci-username-variable and --oci-password-variable (#48189)
• Docs: ensure Getting Started has bootstrap list output in correct place (#48281)
• CI: allow GitHub actions to run on forks of Spack with different project name (#48041)
• CI: make unit tests work on Ubuntu 24.04 (#48151)
• CI: re-enable cray pipelines (#47697)

Package updates

• qt-base: fix rpath for dependents (#47424)
• gdk-pixbuf: fix outdated URL (#47825)

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:

• Fixed support for compilers other than GCC, LLVM, and Intel
• Fixed support for reading Cray manifest file. Now compilers from Cray manifest are added as externals in the packages.yaml file
• Turned the compiler wrapper into its own package. This means the compiler-wrapper is now part of the DAG, and any change to the wrapper script is reflected in the DAG hash.

Many package recipes have also been fixed, with respect to:

• how they use compilers
• how they use language dependencies

We are continuing work towards having ✔️ pipelines

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

• Compiler wrappers are added last to PATH. This fixes a bug where the path to real compiler could be prepended to the path of the wrappers in PATH, mostly relevant for RH linux systems.
• Add a rule to the solver to force compilers being externals. This prevents concretizing against yet to be built compilers, since we don't have the machinery to make them work at install time, yet.
• Fixed support for OneAPI compilers

Many package recipes have also been fixed, with respect to:

• how they use compilers
• how they use language dependencies

We are working towards having ✔️ pipelines

Spack v1.0.0-alpha.1 is the very first pre-release for the v1.0.0 release, expected in June 2025. It is intended to allow testing of #45189 on existing workflows, before it is merged to develop.

Highlights

In this pre-release, compilers stop being a node attribute, and become a build-only dependency.

Packages may declare a dependency on the c, cxx, or fortran languages, which are now treated as virtuals, and compilers would be providers for one or more of those languages. Compilers can also inject runtime dependency, on the node being compiled. An example graph for zlib-ng is the following:

Here gcc is used for both the c, and cxx languages, as shown by the virtuals= annotations on the edges. gcc also injects gcc-runtime on the nodes being compiled. This change in the model has implications, among other things, on the semantic of the % sigil, as discussed in #44379, and implies a version bump in the Specfile, Database and Lockfile format.

Breaking changes

The following changes are by design, and supposed to stay in v1.0.0

node.satisfies("%gcc")

parent["child"]

# This one raises an Exception, since "parent" does not depend on cmake
parent["cmake"]
# This one is ok
cmake = parent["hdf5"]["cmake"]

Deprecations

The following configuration options have been deprecated:

Other notable changes

• The tokens {compiler}, {compiler.version}, and {compiler.name} in Spec.format expand to "none" if a Spec does not depend on C, C++, or Fortran.
• The default install tree layout is now "{architecture.platform}/{architecture.target}/{name}-{version}-{hash}"

Known limitations and bugs

Below we list limitations that are known to be in v1.0.0-alpha.1, and we intend to fix before v1.0.0

matrix:
- [x, y, z]
- [%gcc, %clang]

matrix:
- [x, y, z]
- prefer: [%gcc, %clang]

packages:
  hdf5:
    externals:
    - spec: hdf5@1.12 %gcc
      prefix: /prefix/gcc
    - spec: hdf5@1.12 %clang
      prefix: /prefix/clang

$ spack install gcc@14 %gcc@10.5.0

spack install %gcc@14