config: fix SPACK_DISABLE_LOCAL_CONFIG, remove $user_config_path#27022
config: fix SPACK_DISABLE_LOCAL_CONFIG, remove $user_config_path#27022
SPACK_DISABLE_LOCAL_CONFIG, remove $user_config_path#27022Conversation
spackbot-app
bot
added
defaults
documentation
|
@mathstuf: does this fix your issue? |
tgamblin
changed the title
SPACK_DISABLE_LOCAL_CONFIG remove $user_config_pathSPACK_DISABLE_LOCAL_CONFIG, remove $user_config_path
There were some loose ends left in ##26735 that cause errors when using `SPACK_DISABLE_LOCAL_CONFIG`. - [x] Fix hard-coded `~/.spack` references in `install_test.py` and `monitor.py` Also, if `SPACK_DISABLE_LOCAL_CONFIG` is used, there is the issue that `$user_config_path`, when used in configuration files, makes no sense, because there is no user config scope. Since we already have `$user_cache_path` in configuration files, and since there really shouldn't be *any* data stored in a configuration scope (which is what you'd configure in `config.yaml`/`bootstrap.yaml`/etc., this just removes `$user_config_path`. There will *always* be a `$user_cache_path`, as Spack needs to write files, but we shouldn't rely on the existence of a particular configuration scope in the Spack code, as scopes are configurable, both in number and location. - [x] Remove `$user_config_path` substitution. - [x] Fix reference to `$user_config_path` in `etc/spack/deaults/bootstrap.yaml` to refer to `$user_cache_path`, which is where it was intended to be.
tgamblin
force-pushed
the
bugfix/disable-local-config
branch
from
175b02b to
31ed504
Compare
|
I think this should do it. Am I reading correctly that this still allows the user_config_path to be set, and that will be used as the user config directory, but there's no way to name it in the config files? I mean that's probably ok, it just means we can't do things like refer to a subdirectory of it for another chunk of config or similar. |
Yep that's correct. We don't name any other config directories and I think we shouldn't -- the way the config system is designed (for testing, in production, etc.) any config scope could go away, so I think we shouldn't refer to them. Instead, refer to |
|
Ok. Honestly I think we should actually have a data path, separate from a cache path, as well but that's a discussion for later post-0.17 PR. |
|
I think I'm happy with this solution too, I didn't go for it because I thought some felt strongly about having the bootstrap dir shared among instances by default, whereas provider cache must be different between instances. My only hesitation is that it may be unexpected that spack writes to $spack/etc/spack, but then again, alternative one can set spack_user_[config|cache]_path (and /etc/spack is almost never set anyways), and those dirs are easy to delete. ($spack/etc/spack is not "easy" to delete, since |
|
Much as it's true it's not easy to delete, it is easy to revert it with a bit of |
|
We should probably one day move the "site" config scope (which I also want to rename the "spack" config scope) to a subdirectory of |
3 participants
Closes #27010.
There were some loose ends left in ##26735 that cause errors when using
SPACK_DISABLE_LOCAL_CONFIG.~/.spackreferences ininstall_test.pyandmonitor.pyAlso, if
SPACK_DISABLE_LOCAL_CONFIGis used, there is the issue that$user_config_path, when used in configuration files, makes no sense, because there is no user config scope.Since we already have
$user_cache_pathin configuration files, and since there really shouldn't be any data stored in a configuration scope (which is what you'd configure inconfig.yaml/bootstrap.yaml/etc., this just removes$user_config_path.There will always be a
$user_cache_path, as Spack needs to write files, but we shouldn't rely on the existence of a particular configuration scope in the Spack code, as scopes are configurable, both in number and location.$user_config_pathsubstitution.$user_config_pathinetc/spack/deaults/bootstrap.yamlto refer to$user_cache_path, which is where it was intended to be.