Glossary¶

This page collects definitions for the terms that appear throughout the Spack documentation. For an alphabetic list of every documented keyword and environment variable, see the general index.

abstract spec¶: A spec that is only partially specified. Missing fields (version, variants, compiler, dependencies) are filled in during concretization. Anything a user types on the command line is an abstract spec until it is concretized. See also concrete spec.
anonymous environment¶
independent environment¶: An environment activated by directory path (spack env activate ./my-env). Not registered under a name. See Independent Environments.
anonymous spec¶: A spec without a package name, used to express constraints that should apply to any package matching it (for example as selection patterns in configuration files). See Selective environment modifications.
architecture spec¶: The platform, operating system, and target microarchitecture for a build, written as arch=platform-os-target (e.g. arch=linux-ubuntu22.04-zen3). See Architecture specifiers.
binary mirror¶
buildcache¶: A mirror that hosts pre-built binary packages. Spack can both push to and install from build caches. See Build Caches.
bootstrap¶: The process by which Spack provisions its own runtime dependencies (clingo, gnupg, patchelf) on a fresh system. See Bootstrapping.
build cache index¶: A JSON manifest in a buildcache listing every binary it contains together with their hashes and dependencies. The concretizer downloads it (or its manifest equivalent in an OCI buildcache) to decide which binaries are eligible for reuse without fetching every individual spec. Refreshed with spack buildcache update-index and spack buildcache push --update-index; see Build Caches.
build environment¶: The shell environment Spack constructs for a package’s build: PATH, CC / CXX / FC pointing at the compiler wrappers, CMAKE_PREFIX_PATH, PKG_CONFIG_PATH, jobserver MAKEFLAGS, and any variables set by setup_build_environment or by dependencies’ setup_dependent_build_environment. Variables that could pull unintended system libraries into the build (LD_LIBRARY_PATH, CPATH, LIBRARY_PATH, PYTHONPATH, …) are unset. spack build-env <spec> prints it; passing a shell as the command (spack build-env <spec> sh) drops you into it, and --dump / --pickle write it to a file.
build job¶: A unit of work scheduled against the jobserver (e.g. a single cc invocation). spack install -j<N> (or config:build_jobs) caps the total number of in-flight build jobs across all concurrently building packages.
build system¶: A mixin base class that knows how to drive a particular build tool: Package, CMakePackage, AutotoolsPackage, MesonPackage, and so on. See Build Systems.
chained install tree¶: A read-only upstream store made available to a downstream Spack instance so its installs can be reused. See Chaining Spack Installations (upstreams.yaml).
CI pipeline¶: A generated GitLab pipeline that builds and pushes binaries for the specs in an environment. See CI Pipelines.
clingo¶: The Answer Set Programming (ASP) solver used by the concretizer.
compiler flags¶: Flags injected at build time via spec syntax, namespaced by language: cflags, cxxflags, fflags, cppflags, ldflags, ldlibs. See Compiler flags.
compiler wrapper¶: A shell script that sits between the build system and the real compiler: it rewrites the command line, injects include, library, and RPATH flags for dependencies, and then invokes the underlying compiler. The wrappers are provided by the compiler-wrapper package, which is automatically injected as a dependency of every package that depends on a language virtual (c, cxx, fortran); the build environment points CC / CXX / FC at the wrapper executables. See Compiler wrappers and flags.
concrete spec¶: A fully specified spec in which every field is fixed: an exact version, all variant values, a compiler, an architecture, and a concrete spec for every dependency in the DAG. Concrete specs are what Spack actually installs; they are identified by a DAG hash. See also abstract spec.
concretization¶: The process of turning an abstract spec and the surrounding configuration into a concrete spec DAG. Performed by the concretizer.
concretizer¶: Spack’s solver. The current implementation translates specs and package constraints to Answer Set Programming, runs clingo, and reads concrete specs back out. See Concretization Settings (concretizer.yaml).
concurrent packages¶: The maximum number of packages Spack builds in parallel, controlled by spack install -p<N> / --concurrent-packages. Unbounded by default; packages start as jobserver tokens become available.
config.yaml¶: The top-level configuration file controlling install paths, build concurrency, locks, modules, and similar settings. See Spack Settings (config.yaml).
container image¶: A Docker/OCI image of a Spack-built software stack. Spack can produce one either by exporting already-installed specs with spack buildcache push --base-image to an OCI registry, or by generating a Dockerfile / Singularity definition from an environment with spack containerize. See Container Images.
DAG¶: Directed acyclic graph. A concretized spec is a DAG whose nodes are concrete specs and whose edges are dependencies. It is generally not a tree, because dependencies are shared, and the same package may even appear more than once in different configurations or roles.
DAG hash¶: The cryptographic hash that identifies a concrete spec. Computed over the full DAG (name, version, variants, compiler, flags, arch, and dependency hashes). Used as the directory suffix in the prefix and as the spec’s primary key.
database¶: The JSON-backed index of every installed spec in the store. Acts as a cache so Spack does not need to walk the install tree.
dependency type¶: The role a dependency plays: build (only needed during the build), link (linked into the dependent), run (needed at run time), or test (needed only when running tests). A single depends_on may carry multiple types. See Dependency types.
deprecate¶
deprecation¶: Marking a version (or whole package) as no longer supported. Package authors set deprecated=True on a version(...) directive; spack install then warns and prompts before fetching such a version (spack install --deprecated or config:deprecated:true skips the check), and spack info lists it under “Deprecated versions”. Distinct from spack deprecate, which replaces one installed spec with another in the store by symlinking the old prefix at the new one. See Deprecating old versions.
develop spec¶: A spec that builds from a local source directory instead of a fetched archive, so edits to the sources trigger a rebuild on the next install. It carries a dev_path=<path> variant pointing at the working tree, and is set up with spack develop. See Developing Packages in a Spack Environment.
direct dependency¶: A dependency that appears in a package’s own depends_on declarations, i.e. one edge away in the DAG. In Spec Syntax the % sigil constrains direct dependencies (hdf5 %gcc@15); contrast with transitive dependency.
directive¶: A function called directly in the class body of a package.py to declare package metadata: version, depends_on, variant, provides, conflicts, requires, patch, resource, extends, and so on.
environment¶: A named, declarative collection of root specs plus configuration, stored in spack.yaml, concretized to spack.lock. The unit of reproducible deployments in Spack. See Environments (spack.yaml, spack.lock).
explicit¶: A property of an installed spec recorded in the database. A spec is explicit if it was requested directly: a spack install argument or an environment root spec. Explicit installs are preserved by spack gc. spack mark -e/-i toggles the flag on an existing install, spack find --explicit / --implicit filters by it, and a spec group with explicit: false installs its specs as implicit. See also implicit.
extension¶: A package installed into another package’s prefix-like namespace, most commonly a Python extension installed into a Python site-packages view. See Extensions.
external package¶: A package that is not built by Spack but found on the system and registered through packages.yaml. Used for vendor-provided compilers, MPI, CUDA, system libraries, etc. See External packages.
fetch strategy¶: The mechanism used to obtain a package’s source: a URL tarball, or a checkout from git, hg, svn, or cvs. See Fetching from code repositories.
fresh¶: The concretizer policy of ignoring already-installed and cached specs and solving for the newest configuration allowed by the constraints. Selected with spack install --fresh / spack concretize --fresh; the opposite of reuse. --fresh-roots is a middle ground: solve root specs fresh while still reusing their dependencies.
hook¶: A Python callback built into Spack that runs at a defined point in the install lifecycle (post-install, pre-uninstall, …), for example to generate module files or rewrite shebang lines (sbang). Hooks are fixed in Spack itself; packages instead customize their own builds by wrapping phases with @run_before / @run_after.
implicit¶: The opposite of explicit: a property of an installed spec, recorded in the database, marking that it was only installed as a dependency of something else. Implicit installs become eligible for garbage collection (spack gc) once no installed spec depends on them.
include chain¶: A sequence of include: directives pulling additional YAML files (or environments) into a configuration. See Include Settings (include.yaml).
install tree¶: See store.
jobserver¶: A POSIX jobserver, compatible with GNU Make’s protocol, that bounds the total number of concurrent build jobs across all packages building in parallel. Spack creates one when -j<N> is passed (or inherits an external one from MAKEFLAGS) and forwards it to every package’s build environment. See Installing Packages.
Lmod¶: A Lua-based module system Spack can generate module files for. See also TCL modules.
managed environment¶: An environment stored in Spack’s environment directory and addressed by name (spack env activate myenv).
manifest¶: The spack.yaml file describing an environment: the root specs, configuration overrides, and view settings. Concretizing the manifest produces the spack.lock lockfile.
microarchitecture¶: A specific CPU microarchitecture recognized by archspec (zen3, skylake_avx512, neoverse_v2, …) and used as the target portion of an architecture spec. The concretizer can label nodes either with full microarchitectures or with generic families (x86_64_v3) via concretizer:targets:granularity. See Concretization Settings (concretizer.yaml).
mirror¶: A location (URL or path) holding copies of the artifacts Spack would otherwise fetch from their canonical locations: source tarballs, resources, and patches for source builds, and binary tarballs in the case of a binary mirror. Mirrors are consulted before fetching upstream. See Mirrors (mirrors.yaml).
mirrors.yaml¶: Configuration of source and binary mirrors. See Mirrors (mirrors.yaml).
mixin¶: A package base class that contributes variants, dependencies, and helper methods without being a full build system on its own. CudaPackage, ROCmPackage, and SourceforgePackage are typical examples, combined with a concrete build system via multiple inheritance.
module file¶: A generated file (Lua for Lmod, TCL for environment-modules) that loads a package’s run environment into the user’s shell. See Modules (modules.yaml) and Configuration structure.
module set¶: A named block under modules: in modules.yaml that produces its own collection of module files with its own install root, naming scheme, and inclusion rules. The default set is called default; module commands target it unless --name <set> is given. See Configuration structure.
modules.yaml¶: Configuration of module file generation. See Modules (modules.yaml).
namespace¶: A repo’s identifier (repo.yaml’s namespace: key). Fully qualified package names take the form namespace.name (e.g. builtin.zlib). See Namespaces.
non-redistributable¶: A package whose source or binaries may not be republished, expressed with the redistribute(source=False, binary=False, when=...) directive. spack mirror create and spack buildcache push skip such artifacts by default; --private opts them back in for internal mirrors.
OCI buildcache¶: A buildcache layered into an OCI registry (Docker Hub, GHCR, …) so binaries can be distributed alongside container images. See OCI / Docker V2 Registries as Build Cache.
package¶: A Python class describing how to fetch, configure, build, and install a piece of software; also called a recipe. Lives in a package.py file inside a repository. See Package Fundamentals.
package hash¶: A hash of the package.py source (and its build inputs), tracked so Spack can detect recipe changes. Distinct from the DAG hash.
packages.yaml¶: Per-package configuration: external packages, version preferences, requirements, variants. See Package Settings (packages.yaml).
patch¶: A source patch applied to a package before configuring. Declared with the patch(...) directive; see Patches.
phase¶
build phase¶
install phase¶: One step of a build system’s install lifecycle. The ordered list lives in the builder’s phases attribute, for example ("configure", "build", "install") for autotools or ("cmake", "build", "install") for CMake. Each phase is a method on the builder class and can be overridden, replaced, or wrapped with @run_before / @run_after. The final install phase is the one that copies the build results into the installation prefix. Note that build phase is often used loosely for any phase in the lifecycle, not just for the phase named build. See Overriding a build phase.
prefix¶: The installation directory of a single concrete spec inside the store. The default layout is <platform>-<target>/<name>-<version>-<hash> relative to the store root.
propagation¶: Pushing a variant value, compiler flag, or dependency choice down through a spec’s dependencies. Written with doubled sigils: ++variant and cflags==-O3 propagate a variant or flag, while %%c,cxx=clang propagates a direct dependency choice (typically the compiler) to the runtime sub-DAG as a strong preference.
provenance¶: Recorded information about how an install was produced: the source checksum or git commit, the compiler and its flags, the patches applied, and any develop-source path. Spack tracks provenance in the per-install install_manifest.json, in the SBOM, and in spec metadata such as the commit variant for git-based versions and the dev_path variant for develop specs.
provider¶: A package that satisfies a virtual package. For example, openmpi and mpich both provide mpi.
recipe¶: See package.
repo¶
repository¶: A directory tree containing package recipes plus a repo.yaml. Multiple repos can be layered, each contributing packages under a namespace. See Package Repositories (repos.yaml).
repos.yaml¶: The list of active package repositories. See Package Repositories (repos.yaml).
requirement¶: A hard constraint declared in packages.yaml under require:. The concretizer must satisfy it or fail. See Package Requirements.
resource¶: An extra archive fetched alongside the main source and unpacked under the build stage. Declared with the resource(...) directive.
reuse¶: The concretizer policy of preferring already-installed or cached specs over rebuilding from scratch. Tunable through concretizer:reuse.
root spec¶
root¶: A spec the user requested directly: an argument to spack install or an entry in an environment’s spack.yaml specs: list. Roots are the starting points of concretization; everything else in the resulting DAG is a dependency pulled in to satisfy a root.
RPATH¶
runpath¶: A linker-embedded library search path baked into installed binaries so they find their dependencies without LD_LIBRARY_PATH. See Runtime library search paths and shared_linking:type.
sandbox¶
sandboxing¶: An opt-in Linux build isolation mode that confines a package’s build phase using Landlock, restricting filesystem and (optionally) network access. Configured under config:sandbox: with allow_read / allow_write paths and an allow_network toggle; intended for reproducibility and bug containment, not as a strict security boundary. See Installing Packages.
sbang¶: Tool that lets Spack use shebang (#!) lines whose length exceeds the operating system’s limit, by rewriting them through a post-install hook.
SBOM¶: A Software Bill of Materials emitted by Spack in SPDX-2.3 format for every installation. Written under <prefix>/.spack/sbom/ and meets NTIA minimum elements. See Software Bill of Materials (SBOM).
scope¶
configuration scope¶: A named layer of YAML configuration. Examples are the defaults scope shipped with Spack, the site scope for a single Spack instance, and the user scope in ~/.spack; settings in higher-precedence scopes override lower ones, and command-line flags override them all. spack config scopes lists the active scopes in precedence order. See Configuration Scopes.
sigil¶
spec sigil¶: A punctuation token that introduces the next component of a spec in spec syntax: @ (version), % (direct dependency, including compilers), ^ (transitive dependency), + / ~ (boolean variants), / (DAG hash), and the doubled forms ++ / ~~ / == / %% for propagation. Each sigil is also indexed individually under spec sigil in the general index.
signing¶: Cryptographic signing of buildcache contents with GPG so installers can verify provenance. See Spack Package Signing.
spack instance¶: A Spack installation itself, addressable in config as $spack. In the context of chained install trees, “upstream instance” is often used informally to refer to that instance’s store.
spack.lock¶: The concretized lockfile of an environment: a frozen DAG of concrete specs that Spack reuses across activations and machines.
spack.yaml¶: The human-edited manifest of an environment: the specs to build, the configuration overrides, and the view settings.
spec¶: A description of a package configuration: name, version, variants, compiler, flags, architecture, and dependencies. Specs are Spack’s central data structure and the syntax users type on the command line. See Spec Syntax and Spec Syntax. See also abstract spec, concrete spec, root spec, anonymous spec, spec syntax, explicit.
spec group¶: A named set of specs inside an environment, sharing constraints and concretization rules. See Spec Groups.
spec syntax¶: The textual language used to write specs, built from sigils: version (@), direct dependencies including compilers (%), transitive dependencies (^), variants (+ / ~ / name=value), flags (cflags=...), architecture (arch=...), and hashes (/). See Spec Syntax.
splicing¶: Replacing a dependency in a concrete spec with a different, ABI-compatible spec providing the same package or virtual package. Often used to swap a generic buildcache MPI for a site-tuned one. See Splicing and Specifying ABI Compatibility.
stage¶: The temporary working directory where a package’s sources are unpacked and built.
stand-alone test¶: A test defined by a package’s test_* methods and executed after installation by spack test run against an installed prefix. Distinct from build-time tests run during the check build phase of an autotools/cmake build. See Stand-alone tests and the testing section of the packaging guide.
sticky variant¶: A variant the concretizer is not allowed to flip silently. The user (or a requirement) must set its value explicitly.
store¶: The directory tree where Spack installs packages, one prefix per concrete spec; also called the install tree. Backed by a database that indexes every install.
strong preference¶: A soft constraint declared in packages.yaml under prefer:. The concretizer tries to satisfy it, but may ignore it if it cannot be met. See Conflicts and strong preferences.
target¶: The microarchitecture portion of an architecture spec, resolved by archspec (e.g. zen3, skylake_avx512, neoverse_v2).
TCL modules¶: The module system of the environment-modules project, whose module files are written in TCL. One of the two module systems Spack generates module files for; the other is Lmod.
toolchain¶: A reusable bundle of compiler and library choices that packages can opt into, configured in toolchains.yaml. See Toolchains (toolchains.yaml).
transitive dependency¶: A dependency reachable through one or more intermediate packages, i.e. a dependency of a dependency. The ^ sigil constrains transitive dependencies (hdf5 ^hwloc+cuda). A view’s link: run / link: all options pull in root spec transitive dependencies of the corresponding types.
upstream¶: Another spack instance whose store is registered (via upstreams.yaml) as a read-only source of installed packages for the local instance. See Chaining Spack Installations (upstreams.yaml).
variant¶: A named build option on a package. Variants can be boolean (+mpi / ~mpi), single-valued (build_type=Release), or multi-valued (fabrics=verbs,psm). See Variants.
version¶: A specific release of a package, declared in package.py with the version(...) directive. Versions are ordered and can be compared, e.g. @1.2:1.4. See Version specifier.
version list¶: A comma-separated set of versions or ranges, e.g. @1.2,1.4:1.6.
version range¶: A constraint of the form @low:high, @low:, or @:high that matches any version inside the interval.
view¶: A unified directory (symlinks, hardlinks, or copies) projecting an environment’s installs into one tree, suitable for PATH-style use. See Minimal view configuration.
virtual package¶: A name (such as mpi, blas, lapack, or c) that represents an interface rather than a concrete implementation. Real packages provide virtuals.