Spack environment
Spack package manager environment file
| Type | object |
|---|---|
| File match |
spack.yaml
|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/spack-environment/latest.json |
| Source | https://raw.githubusercontent.com/spack/schemas/refs/heads/main/schemas/spack.json |
Validate with Lintel
npx @lintel/lintel checkProperties
Spack environment configuration, including specs, view, and any other config section (config, packages, concretizer, mirrors, etc.)
{}20 nested properties
Configure how Spack bootstraps its own dependencies when needed
4 nested properties
Enable or disable bootstrapping entirely
Where to install bootstrapped dependencies
List of bootstrap sources tried in order. Each method may bootstrap different software depending on its type (e.g., pre-built binaries, source builds)
Controls which sources are enabled for automatic bootstrapping
Configuration for uploading build results to CDash
4 nested properties
Unique build group name for this stack
CDash server URL
CDash project name
Site identifier for CDash reporting
Concretizer configuration that controls dependency selection, package reuse, and solver behavior
14 nested properties
Force re-concretization when concretizing environments
Controls how aggressively Spack reuses installed packages and build caches during concretization
Enable node namespace functionality in the concretizer
Controls which target microarchitectures are considered during concretization
2 nested properties
If true, only allow targets compatible with the current host; if false, allow any target (e.g., concretize for icelake while running on haswell)
Target selection granularity: 'microarchitectures' (e.g., haswell, skylake) or 'generic' (e.g., x86_64_v3, aarch64)
Controls whether environment specs are concretized together or separately
Whether to allow compiler mixing between link/run dependencies
Configuration for spec splicing: replacing dependencies with ABI-compatible alternatives to improve package reuse
2 nested properties
List of explicit splice configurations to replace specific dependencies
[]Enable automatic splicing for ABI-compatible packages (experimental feature)
Controls whether the dependency graph can contain multiple configurations of the same package
2 nested properties
Duplication strategy: 'none' (single config per package), 'minimal' (allow build-tools duplicates), 'full' (experimental: allow full build-tool stack separation)
Maximum number of duplicates allowed per package when using strategies that permit duplicates
Enable static analysis to reduce concretization time by generating smaller ASP problems
Maximum time in seconds for the solve phase (0 means no time limit)
If true, timeout always results in error; if false, use best suboptimal solution found before timeout (yields unreproducible results)
Compatibility mapping between operating systems for reuse of compilers and packages (key: target OS, value: list of compatible source OSes)
Configuration for caching solver outputs from successful concretization runs
3 nested properties
Whether to utilize a cache of solver outputs from successful concretization runs
Path to the location where Spack will root the concretization cache
Limit on the number of concretization results that Spack will cache (0 disables pruning)
Configuration for how Spack handles external packages during concretization
1 nested properties
Controls how missing information (variants, etc.) is completed for external packages: 'architecture_only' completes only mandatory architectural information; 'default_variants' also completes missing variants using their default values
Spack's basic configuration options
{}36 nested properties
Build flag configuration options
1 nested properties
Whether to keep -Werror flags active in package builds
Control how shared libraries are located at runtime on Linux
Installation tree configuration
3 nested properties
The location where Spack will install packages and their dependencies
Length to pad installation paths to allow better relocation of binaries (true for max length, integer for specific length)
Customize directory structure and naming schemes by mapping specs to format strings.
Length of hash used in installation directory names
Temporary locations Spack can try to use for builds
Name format for build stage directories
Name for development spec build stage directories
Directory in which to run tests and store test results
List of Spack extensions to load
Locations where templates should be found
Directory where licenses should be located
Location to cache downloaded tarballs and repositories
Temporary directory to store long-lived cache files, such as indices of packages
Directory where Spack managed environments are created and stored
Abort downloads after this many seconds if no data is received (0 disables timeout)
When true, Spack will verify certificates of remote hosts when making SSL connections
Path to custom certificates for SSL verification
Suppress GPG warnings from binary package verification
Enable debug mode for additional logging
When true, Spack verifies downloaded source code using checksums
If true, Spack will fetch deprecated versions without warning
When true, concurrent instances of Spack will use locks to avoid conflicts (strongly recommended)
When true, builds will NOT clean potentially harmful variables from the environment
The language the build environment will use (C for English, empty string for user's environment)
The maximum number of jobs to use for the build system (e.g. make -j), defaults to 16
The maximum number of concurrent package builds a single Spack instance will run
When true, Spack's compiler wrapper will use ccache when compiling C and C++
How long to wait to lock the Spack installation database
How long to wait when attempting to modify a package (null for never timeout)
Allow installation on filesystems that don't allow setgid bit manipulation
Whether to show status information in the terminal title during the build
The default URL fetch method to use (urllib or curl)
Additional paths to search for external packages
Number of seconds a buildcache's index.json is cached locally before probing for updates
A mapping of aliases that can be used to define new Spack commands
Which installer to use. The new installer is experimental.
9 nested properties
4 nested properties
{}4 nested properties
{}5 nested properties
Named spec lists to be referred to with $name in the specs section of environments
[]Configuration for local development of Spack packages
{}Environment variable modifications to apply at runtime
{}5 nested properties
Environment variables to set to specific values
Environment variables to remove/unset
[]Environment variables to prepend values to (typically PATH-like variables)
Environment variables to append values to (typically PATH-like variables)
Values to remove from PATH-like environment variables
Include external configuration files to pull in configuration from other files/URLs for modular and reusable configurations
[]Configure local and remote mirrors that provide repositories of source tarballs and binary build caches for faster package installation
{}Configure automatic generation of module files for Environment Modules and Lmod to manage user environments at HPC centers
1 nested properties
Global prefix inspection settings that apply to all module sets, controlling which subdirectories are added to environment variables
Package-specific build settings and external package configurations
{}1 nested properties
Default settings that apply to all packages (can be overridden by package-specific settings)
{}10 nested properties
Package requirements that must be satisfied during concretization
Strong package preferences that influence concretization without imposing hard constraints
Package conflicts that prevent certain spec combinations
Ordered list of soft preferences for target architectures for all packages (ignored if the concretizer can reuse existing installations)
[]Soft preferences for compiler specs for all packages (deprecated)
[]Whether packages should be built from source (false prevents building)
File permissions settings for package installations
Class-level attributes to assign to package instances (accessible in package.py methods)
Soft preferences for providers of virtual packages (ignored if the concretizer can reuse existing installations)
{}Soft variant preferences as a single spec string or list of variant specifications (ignored if the concretizer can reuse existing installations)
Configuration for package repositories that Spack searches for packages
{}Define named compiler sets (toolchains) that group compiler constraints under a single user-defined name for easy reference with specs like %my_toolchain
{}Configuration for chaining Spack installations. Point this Spack instance to other Spack installations to use their installed packages
{}Environment filesystem view configuration for creating a directory with traditional structure where all files of installed packages are linked
List of specs to include in the environment, supporting both simple specs and matrix configurations
[]List of paths to other environments. Includes concrete specs from their spack.lock files without modifying the source environments. Useful for phased deployments where you want to build on existing concrete specs.
[]