riga
commented
11 months ago With 52fe3f9, config sections of sandboxes are not constructed dynamically any longer via <sandbox_type>_sandbox (in your case to singularity_dev_sandbox(|_env|_volumes)).
The leading sandbox_type is now replaced with config_section_prefix which has to be defined per Sandbox class, but can be inherited. The base sandboxes coming with law (Bash, Venv, Docker, Singularity, CMSSW) define this prefix, so that your SingularityDev sandbox will now check the singularity_sandbox(|_env|_volumes) sections which should always exist.
Alternatively you can set the class attribute config_section_prefix to "singularity_dev" and put
class SingularityDevSandbox(law.singularity.SingularitySandbox):
config_section_prefix = "singularity_dev"
...
law.config.update({
"singularity_dev": {
"stagein_dir_name": "stagein",
"stageout_dir_name": "stageout",
"law_executable": "law",
},
"singularity_dev_env": {},
"singularity_dev_volumes": {},
})under your class definition to register the minimal set of required options.
alecgunny
Full reproducing code can be found here, this issue is concerned with issue 2 on that repo's README. In particular, trying to implement a custom
Sandboxsubclass causes issues at runtime with the Config looks for the corresponding section and finds it doesn't exist. Using the example above, if thesandbox_typeis called"singularity_dev", you might see something like:Haven't looked too much into how arguments get registered with the
Config, but could this potentially be handled by a metaclass forSandboxthat automatically registers itsconfig_defaultswith the globalConfig, maybe via astaticmethodon the class being registered?