diff options
author | Peter Scheibel <scheibel1@llnl.gov> | 2023-12-18 00:47:53 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-12-18 00:47:53 -0800 |
commit | 14c7bfe9cedaa779717852aef6520761ffe95cd3 (patch) | |
tree | b533c09969bb4422aea41521274251f6f6782624 /bin | |
parent | ed52b505d4132f411f15d9764d4bd014c76af8dd (diff) | |
download | spack-14c7bfe9cedaa779717852aef6520761ffe95cd3.tar.gz spack-14c7bfe9cedaa779717852aef6520761ffe95cd3.tar.bz2 spack-14c7bfe9cedaa779717852aef6520761ffe95cd3.tar.xz spack-14c7bfe9cedaa779717852aef6520761ffe95cd3.zip |
`spack develop`: convert to config (#35273)
Convert the 'develop' section of an environment to a dedicated configuration section.
This means for example that instead of having to define `develop` specs in the
`spack.yaml`, the environment can `include:` another `develop.yaml` configuration
which specifies which specs should be developed in the environment.
This change is not expected to be disruptive given that existing environment `spack.yaml`
files will conform to the new schema.
(Update 11/28/2023) I have implemented the `develop`/`undevelop` commands in terms
of more-generic modification functions added to the `config` module: `change_or_add`
and `update_all`. It is assumed that the semantics added here (described in 11/18 update)
would be desirable to extend to other config update actions (e.g. adding compilers,
changing package requirements, adding mirrors).
(Update 11/18/2023) I have updated this such that `spack develop`, and
`spack undevelop` to potentially modify all writable scopes, like
https://github.com/spack/spack/pull/41147. https://github.com/spack/spack/pull/35307
will be useful for modifying included scopes, but generally speaking specifying a
`--scope` will not be required for `spack develop`: `spack develop` will add new
develop specs to whatever scope already has develop specs defined, or to the
highest-priority writable scope (which should be the env scope).
TODOs:
- [x] If you `spack undevelop` a package which is mentioned at multiple layers of
configuration, then currently this would only modify one of them. That's not
technically a new issue (has always existed for configuration modification), but
may be confusing to users when presented via an interface other than `spack config set`
- [x] Need to add (or confirm) the ability to modify individual config files by providing
a path (rather than using a scope identifier as a key to retrieve associated config).
- [x] `spack develop` adds new develop specs to the scope that defines them
(potentially skipping higher priority scopes to e.g. augment included scope files)
---------
Co-authored-by: scheibelp <scheibelp@users.noreply.github.com>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions