Hydra: [Bug] Hydra fails to instantiate objects in specific cases

[shagunsodhani]

🐛 Bug

Hydra fails to instantiate when the caller expects an arg called params and the value is not a supported primitive type.

To reproduce

https://colab.research.google.com/drive/16jOM9kKwSpu1DdUcJETMe6LOz0G9Gnqh?usp=sharing

* Stack trace/error message *

UnsupportedValueType: Value 'Parameter' is not a supported primitive type
    full_key: params[0]
    reference_type=Optional[List[Any]]
    object_type=list

Expected Behavior

No Exception

System information

• Hydra Version : 1.0.0rc1
• Python version : 3.7
• Virtual environment type and version : NA
• Operating system : Ubuntu

Additional context

NA

[BartekRoszak]

A similar issue appears when instantiating with additional params:

tr_sys = hydra.utils.instantiate(cfg.system,
                                     hparams=cfg,
                                     logger=wandb_logger,
                                     n_gpus=n_gpus)

omegaconf.errors.ConfigKeyError: Key 'n_gpus' in not in struct
        full_key: system.params.n_gpus
        reference_type=Optional[Dict[Any, Any]]
        object_type=dict

[omry]

BartekRoszak,
Why is n_gpus not in the cfg.system?
This can be fixed in Hydra, but honestly I think it tells you that your config is wrong.

[BartekRoszak]

n_gpus value is computed at the beginning of the script and I am using it in few places so it is comfortable for me to set it in such a way and it worked well in the previous version.

[omry]

1. If it appears in multiple places in your config you should use interpolation to define it once and use it in multiple places:

num_gpus: 1
system:
  num_gpus: ${num_gpus}

1. Alternatively you can define it in your config as missing:

num_gpus: 1
system:
  num_gpus: ???

1. Regardless, I am going to allow passing things that are not in the config in call. but for your case you should probably follow the advice in 1.

[saulzar]

What's the point in allowing extra parameters this way if you're not allowed to use it this way?

I have some shared computation which triggers this exact same problem (and it's not something which can be known before hand to put in the config file...).

[omry]

The point is that there is a bug.
I did not look dug in yet, but the plan is to fix it.
if you don't like it you have three options:

1. fix it and send a PR.
2. wait for me to fix it when I get to it.
3. Come up with your own alternatives to instantiate.

These are the options.
good luck.

[saulzar]

I am sorry my comment appeared more confrontational than it should have - thanks for your clarification (and your great configuration libraries, the concept is very simple yet it is a great improvement in practice).

[omry]

Apology accepted.
Thanks for clearing the air.

The value this is already providing is it allow you to pass-through objects of types not supported in the config.
You can see the existing unit tests here.

Looks like something fell through the cracks (and is potentially a regression in 1.0).

[omry]

@shagunsodhani :
in your collab, this works:

optimizer = hydra.utils.instantiate(config, params=net.parameters())

Did you try this? this seems like an obvious way to do it.

[omry]

727 is fixing the issues reported here, once it's landed you can test on master.

If there are additional problems open separate issues with a minimal repro for each.

[shagunsodhani]

@shagunsodhani :
in your collab, this works:

optimizer = hydra.utils.instantiate(config, params=net.parameters())

Did you try this? this seems like an obvious way to do it.

Yes, this is what I end up using :)

[omry]

This is the correct form to pass-through arguments by name.

Your example on 1.0rc1, with my comments:
https://colab.research.google.com/drive/1AG7PL5hmzW70gWmgZZAbqHdP4oLGDcA6

Your example on 1.0.rc2 (master) , with my comments:
https://colab.research.google.com/drive/1L1lNte8Gk5qeqvqw7J22UckJWQjmzgER

[shagunsodhani]

@omry I do not have access to the colab notebooks. I have sent the request for access :)