Hydra: Ability to specify composition order of primary config file

[omry]

There are multiple use cases for having configuration in the users config:

Use it as scaffolding and use defaults to populate it:

defalts:
  - foo: bar

foo:
   a: ???
   b: ???

In the above case foo/bar.yaml can be used to populate a and b.

An alternative approach is to allow the user to override things populated by the defaults from the config file:

defalts:
  - foo: bar

foo:
   a: 10
   b: 20

In this scenario, the user wants to force foo.a and foo.b to specific values.

Those two approaches are conflicting, each one requires a different composition order.
Currently, the supported mode is the first one and the second is not possible.
Composition order is roughly:

• hydra related configs
• user config file
• user provided defaults

The idea is to support explicit specification of when to merge in the users config via a special keyword in the defaults, like _self_.
for example:

defalts:
  - _self_
  - foo: bar

or:

defalts:
  - foo: bar
  - _self_

In the first case, the config file would be composed before foo/bar, in the second one after.

[omry]

cc @erikwijmans , I think this got in your way.
cc @shacoshe

[erikwijmans]

Yeah, the _SELF_ thing would work for my use-case. If possible, could there be a flag to set for the default position of _SELF_? So that you can keep the current method (merge _SELF_ first) as default or change to merge _SELF_ last by default?

[omry]

not sure that would be possible (defaults are evaluated before the rest of the config).

I am starting to think of this order as a default that just works:

1. hydra config groups
2. library config groups (for example your provided configs)
3. user main config file
4. user config groups

Note that a user can still change defaults in previous config groups and that would not change the composition order.

It seems like this would be good alternative to supporting __SELF_ as an ordering method.

Generally, there aren't many use cases of frameworks using Hydra yet, so it's still acceptable to change this behavior.

[erikwijmans]

I think _SELF_ is a good idea regardless of adding framework integration support as it'll allow defaults to either function as pulling in a schema + default values or populating a schema with default values.

[omry]

The primary motivation here is to address the framework use case better.

__SELF__ might be useful, but it's already weird because hydra has it's own defaults list that is being merged before the user defaults list, so something like:

defaults:
   - _SELF_
   - hydra/launcher: my_launcher

would actually result in hydra/launcher being merged in before _SELF_.
There is a task to consider allowing other files to provide their own defaults (making the hydra special case a norm). those things are all interacting with one another.

There might still be room for it though, but I would want to explore it once things settles down as implementing it early might limit the design space.

by the way, a less magical form of this is to specify the file name:

my_config.yaml:

defaults:
   - my_config
   - foo: bar

[omry]

switching to target to 1.1.0 as there is a workaround for now and this is a big change with significant implications.