Replies: 3 comments 19 replies
-
|
Aside from What do you all think about an from hydra_zen import builds, instantiate, to_yaml
from omegaconf import OmegaConf
class Model:
interpolations = {
'crop_height': '${dataset:crop_height}',
'crop_width': '${dataset:crop_width}'}
def __init__(self, crop_height: int = 224, crop_width: int = 224):
pass
# Basic Python (could be used elsewhere in broader library)
python_model = Model()
# Hydra script usage (with registered dummy interpolation)
ModelConf = builds(Model, **Model.interpolations)
OmegaConf.register_new_resolver('dataset', lambda _: 224)
print(to_yaml(ModelConf))
hydra_model = instantiate(ModelConf) |
Beta Was this translation helpful? Give feedback.
-
My main concern with this approach is that is encourages a design such that the end-user's config creation code is somewhat cryptic. I.e. I prefer the form cfg = builds(obj, **obj.interpolations)because it makes clear to the reader that the config is being populated by a dictionary stored on cfg = builds(obj)requires the user to know both that Of course, you are free to ship/use your own extension of def auto_builds(obj, *args, **kwargs):
builtin_kwargs = obj.get('interpolations', {})
if isinstance(builtin_kwargs, dict):
kwargs.update(builtin_kwargs)
return builds(obj, *args, **kwargs)That all being said, I appreciate you asking this question because it makes me think about how hydra-zen might design/promote this sort of functionality in a standardized for library authors to leverage. I have some thoughts on this that are stewing, and I will share them with you asap 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I understand the concerns around the cryptic behavior. Keep me posted what you come up with - like you mentioned I think it's a good opportunity to define a community best-practice for this so everyone doesn't go around rolling their own extensions of |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about it some more, I might lean towards an interface like this class MyClass:
__hydra__ = {
'interpolations': {},
'defaults': []}I like that it indicates an important internal, object-orientated property similar to |
Beta Was this translation helpful? Give feedback.
-
|
Right, a nice thing about a name like I want to make sure I understand your ultimate goals here. Is it correct to say that you want to:
Is that correct? Anything missing? |
Beta Was this translation helpful? Give feedback.
-
|
Yes that's a great summary. My main takeaway - similar to how the type annotations/init signature of the class drive the behavior of The only thing missing is the concept of a |
Beta Was this translation helpful? Give feedback.
-
|
Similar to the interpolations thread above, I'm trying to figure out the best way to allow Currently, the only option I can think of is from dataclasses import field
from hydra_zen import builds
from lib import MyClass
Config = builds(MyClass)
defaults_list = field(default_factory=lambda: getattr(MyClass, 'defaults', []))
Config.__dataclass_fields__.update({'defaults': defaults_list})Although this has the same issue with cryptic behavior raised by @rsokl above |
Beta Was this translation helpful? Give feedback.
-
|
Gotchya, and thanks for the link. Your use case does make sense to me. Right now I am leaning towards supporting |
Beta Was this translation helpful? Give feedback.
-
|
I tested out the |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, I tend to limit my config group usages to rather simple cases (like this), so I don't have much insights when it comes to matters like One thing to note, there seems to be a typo in your example. You store the group named but then your |
Beta Was this translation helpful? Give feedback.
-
|
For reference, one of the Hydra devs replied on their thread with the correct package syntax |
Beta Was this translation helpful? Give feedback.
-
|
@addisonklinke FYI: #264 |
Beta Was this translation helpful? Give feedback.
-
|
@rsokl I'm running into the "Config Defaults for Objects" issue you mentioned. I wanted to have a default model optimizer while being able to select alternates via CLI overrides. I tried making the problematic config group have a default of # Contents of demo.py
from dataclasses import dataclass, field
from functools import partial
from typing import Any, List
import hydra
from hydra.core.config_store import ConfigStore
from hydra_zen import builds
from omegaconf import OmegaConf, MISSING
from torch import optim
@dataclass
class Conf:
defaults: List[Any] = field(default_factory=lambda: [
{'model/optimizer': None}
])
model: Any = MISSING
class BaseModel:
def __init__(self, optimizer=partial(optim.Adam)):
pass
def register_configs():
AdadeltaConf = builds(optim.Adadelta, populate_full_signature=True, zen_partial=True)
cs = ConfigStore.instance()
cs.store('config', Conf)
cs.store(group='model', name='base', node=builds(BaseModel, populate_full_signature=True))
cs.store(group='model/optimizer', name='Adadelta', node=AdadeltaConf)
@hydra.main(config_name='config', config_path=None)
def main(cfg):
resolved_cfg = OmegaConf.to_container(cfg, resolve=True, enum_to_str=True)
print(OmegaConf.to_yaml(resolved_cfg))
if __name__ == '__main__':
register_configs()
main()Works fine without overriding the optimizer (minus the fact that the recursive $ python demo.py +model=base
model:
_target_: __main__.BaseModel
optimizer:
_target_: torch.optim.adam.Adam
_partial_: trueBut you can't pick an alternative optimizer $ python demo.py +model=base model/optimizer=Adadelta
In 'model/base': Validation error while composing config:
Merge error: PartialBuilds_Adam is not a subclass of PartialBuilds_Adadelta. value: {'_target_': 'torch.optim.adam.Adam', '_partial_': True}
full_key:
object_type=Conf |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure why specifying the default of class BaseModel:
def __init__(self, optimizer=partial(optim.Adam)):
pass
cs.store(group='model', name='base', node=builds(BaseModel, populate_full_signature=True))leads to the creation of @jgbos do you have any ideas for workarounds? |
Beta Was this translation helpful? Give feedback.
-
|
I think the only solution is to remove the default def nonefn():
return None
cs.store(name="none", group="model/optimizer", node=builds(nonefn))and set |
Beta Was this translation helpful? Give feedback.
-
|
@jgbos I was trying
Strongly agree - there seem to be some pretty similar discussions around this use case
One suggestion in those threads is to leave the node empty to begin with (which is what I think @rsokl and I were going for with the |
Beta Was this translation helpful? Give feedback.
-
|
@addisonklinke ah, sorry. I didn't catch the default in |
Beta Was this translation helpful? Give feedback.
-
A list of "gotchyas":
Configuring "Interactive" Functions
Be careful configuring functions defined in interactive modes for reproducibility.
OmegaConf Interpolations
Be careful in setting OmegaConf interpolations as defaults.
Config Defaults for Objects
If you need to override "objects" in a config you must set those objects to
Nonein your configuration.Submitit-Launcher and Environment
If you try to submit jobs from an interactive node on Slurm you should first remove the environment variables for Slurm since submitit copies the current environment.
Beta Was this translation helpful? Give feedback.
All reactions