Architecture
Package
“Source code” describing a piece of software and how to build it (actually a Python class, defined in package.py), in a directory with any patches that might need to be applied first. The Spack Packaging Guide has details about creating and maintaining packages (https://spack.readthedocs.io/en/latest/packaging_guide.html).
Repo
A collection (“repository” of packages. Almost everything is in the “builtin” repo, but Spack has a “repos” config section where you can specify locations and order of repos to search. See the Spack package repository documentation (https://spack.readthedocs.io/en/latest/repositories.html).
Spec
Spack defines a domain-specific-language for describing the build parameters and dependencies with which a package was, or should be, built. The Spack specs and dependencies documentation describes this in detail (https://spack.readthedocs.io/en/latest/basic_usage.html#specs-dependencies).
Variant
A variant is a selectable build option for a package. Available variants for a package are defined in the Spack package. You can, in spec, enable (+) or disable(- or ~) or set (name=value) a variant. Variants usually correspond to a ./configure or cmake setting.
Installation tree
A directory for Spack-installed software. Spack allows specifications of a directory structure and naming convention for installed software. At ARC, this defaults to your $HOME directories .spack folder (~/.spack). This can be modified through Spack environments.
Upstream
Spack uses Upstream to satisfy dependencies in other locations, called “upstream” locations. At ARC there are two upstream locations. To view about them, run $ spack config get upstreams
Buildcache
As a way to avoid repeatedly building the same software, Spack supports packaging up built software for reuse. These pre-built packages are held in a “buildcache”, and a subsequent spack installcan simply unpack the cached package, instead of rebuilding it.