Description

It would be nice to support installing one spec (e.g. by hash) that already exists in a concrete environment, but is not currently installed. This could be achieved by providing a --no-add cli option to spack install. Here's how I'm thinking of it:

• The --no-add option defaults to False, but if provided causes spack to install only specifically requested concrete specs and their dependencies, and not add any new specs to the environment.
  • spack install --no-add <specs> fails if any specs provided do not already exist in the current concretized environment.
• Just as without the --no-add option, specs can be provided to spack install as either cli specs (most likely as hashes) or concrete spec yaml file paths.
• If no specs are provided, the --no-add option does not cause an error, but does not have any effect either, since spack install shouldn't add any new specs in a concretized spack environment anyway.

If you try this currently, spack fails when it does not find the spec/hash you provide in the install database.

Example Usage

Get a concrete spack environment that was generated somewhere else, and install a single spec identified by hash (DAG hash in this case). Assume we have the same compilers/os/arch on our current machine as were present wherever the spack.lock file was generated.

$ cd /tmp/test_spack_env
$ unzip ~/Downloads/env.zip 
$ ls
spack.lock  spack.yaml
$ spack env activate -d $(pwd)        
$ spack install /zhcbxzn
checking active environment for zhcbxzn

==> Installing pkgconf-1.7.3-zhcbxznqu7xuml4o5lb5cqumkqqnrzdl

$ spack find -l
==> In environment /tmp/test_spack_env
==> Root specs
-- darwin-None-x86_64 / [email protected] ----------------------
------- vtk%[email protected] ~mpi+osmesa  ------- vtk%[email protected] +python

==> 1 installed package
-- darwin-catalina-x86_64 / [email protected] ------------------
zhcbxzn [email protected]

Rationale

This change is a step toward easier reproduction of GitLab CI job failures outside the deployed cloud environment, by making it easier and more concise to identify a particular spec in an environment where specs are concretized separately (and thus, packages in the environment can have multiple concretizations).

Additional information

If this can be handled during spec parsing, the --no-add option could be possibly be used in other spack commands that work with concrete specs.

This seems closely related to #19085 which aims to do a similar thing for any buildcaches which spack knows about.

General information

$ spack --version
0.16.1-1882-c7c60176fd

• I have run spack --version and reported the version of Spack
• I have searched the issues of this repo and believe this is not a duplicate