diff options
author | Massimiliano Culpo <massimiliano.culpo@gmail.com> | 2020-10-30 21:10:45 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-10-30 13:10:45 -0700 |
commit | 33c3c3c700cf0acd458389526974945e62fe895e (patch) | |
tree | 8f36028cdcab738a8b458a2584b73b7a45c03fa5 /LICENSE-APACHE | |
parent | 458d88eaad3c4e93210915ffa9b3bb64cc52d007 (diff) | |
download | spack-33c3c3c700cf0acd458389526974945e62fe895e.tar.gz spack-33c3c3c700cf0acd458389526974945e62fe895e.tar.bz2 spack-33c3c3c700cf0acd458389526974945e62fe895e.tar.xz spack-33c3c3c700cf0acd458389526974945e62fe895e.zip |
Config: cache results of get_config (#19605)
`config.get_config` now caches the results and returns the same
configuration if called multiple times with the same arguments
(i.e. the same section and scope).
As a consequence, it is expected that users will always call
update methods provided in the `config` module after changing
the configuration (even if manipulating it as a Python nested
dictionary). The following two examples should cover most
scenarios:
* Most configuration update logic in the core (e.g. relating to
adding new compiler) should call `Configuration.update_config`
* Tests that need to change the global configuration should use the
newly-provided `config.replace_config` function.
(if neither of these methods apply, then the essential requirement
is to use a method marked as `_config_mutator`)
Failure to call such a function after modifying the configuration
will lead to unexpected results (e.g. calling `get_config` after
changing the configuration will not reflect the changes since the
first call to get_config).
Diffstat (limited to 'LICENSE-APACHE')
0 files changed, 0 insertions, 0 deletions