Jasha10
commented
2 years ago Hi @thoth291,
Here is a workaround that hopefully will work for you. It involves registering an OmegaConf custom resolver to calculate the set of keys represented by the syntax glob(app.*) that you have proposed:
# simple_app.py
import os
from typing import List
from hydra.core.hydra_config import HydraConfig
import hydra
from omegaconf import DictConfig, OmegaConf
def my_glob_impl(pattern: str, _root_: DictConfig) -> List[str]:
"""
A simple glob implementation, takes a `pattern` with wildcard `*` at the
end. The return value is a set of full keys in the config which match the
`pattern`.
"""
assert pattern.endswith(".*")
pattern = pattern.removesuffix(".*")
node = OmegaConf.select(_root_, key=pattern)
if node is None:
return []
if not isinstance(node, DictConfig):
raise NotImplementedError
else:
return [f"{pattern}.{key}" for key in node.keys()]
OmegaConf.register_new_resolver(name="my_glob", resolver=my_glob_impl)
@hydra.main(config_path=".", config_name="config")
def my_app(_cfg: DictConfig) -> None:
exclude_keys = HydraConfig.get().job.config.override_dirname.exclude_keys
print(f"{exclude_keys=}")
print(f"Working dir: {os.getcwd()}")
if __name__ == "__main__":
my_app()# config.yaml
params:
a: 4
name: test
app:
verbose: false
config: false
setup: true
hydra:
run:
dir: ${hydra.job.name}/single/${now:%Y-%m-%d}/${now:%H-%M-%S}
sweep:
dir: ${hydra.job.name} #_${hydra.job.id}
subdir: ${hydra.job.num}_${hydra.job.override_dirname}
job:
name: ${params.name}
override_dirname: ???
config:
# configuration for the ${hydra.job.override_dirname} runtime variable
override_dirname:
kv_sep: '='
item_sep: ','
# currently I'm using [app.verbose,app.config,app.setup]
exclude_keys: '${my_glob: app.*}'$ # at the command line:
$ $ python3 simple_app.py params.a=4,5,6 app.verbose=true -m
[2021-11-03 19:40:55,849][HYDRA] Launching 3 jobs locally
[2021-11-03 19:40:55,849][HYDRA] #0 : params.a=4 app.verbose=True
exclude_keys=['app.verbose', 'app.config', 'app.setup']
Working dir: /Users/jasha10/hydra_tmp/tmp1873/test/0_params.a=4
[2021-11-03 19:40:55,941][HYDRA] #1 : params.a=5 app.verbose=True
exclude_keys=['app.verbose', 'app.config', 'app.setup']
Working dir: /Users/jasha10/hydra_tmp/tmp1873/test/1_params.a=5
[2021-11-03 19:40:56,054][HYDRA] #2 : params.a=6 app.verbose=True
exclude_keys=['app.verbose', 'app.config', 'app.setup']
Working dir: /Users/jasha10/hydra_tmp/tmp1873/test/2_params.a=6The basic idea is to use the my_glob_impl function to create the list of keys that you want to exclude. If you use this my_glob resolver in your Hydra config, then the _root_ argument passed to my_glob_impl will be the root config that is composed by Hydra. The glob functionality could be made more advanced by e.g. supporting wildcards in multiple places or allowing some recursive expansion (e.g. glob app.** to get all nested keys).
Edit: I've reversed the order of the if not isinstance(node, DictConfig) and the if node is None blocks in the my_glob_impl function body. The if node is None check should come first, as otherwise that if-block will never be reached.
thoth291
🚀 Feature Request
If in my command line I would like to exclude
app.verboseandapp.config- then inoverride_dirnameI could write one of these to make it work:so above line would give me
override_dirname="params.a=4"for one of the sweep tasks.Motivation
This would simplify directory naming for runs and would allow better integration with command line functionality.
Is your feature request related to a problem? Please describe. It's related to issue #1872 - that one also using cmd as primary driver for the sweep setup. And overall both of these issues should make commandline functionality synchronized with yaml file experience users currently have.
Pitch
Describe the solution you'd like The solution would allow to exclude based on more generic criteria - which would simplify robustness towards future life of the configuration of the app.
Describe alternatives you've considered The only alternative is not to use it and configure dirname using custom interpolation and logic. But that would limit generalizability - since user would have to modify this logic each time new argument will be considered for sweeping.
Are you willing to open a pull request? no
Additional context
I will take any workaround which would require to modify only main config.yaml file once and for all possible future sweeps or any custom python logic I need to write into my app.
Thanks in Advance!