Dave Berenbaum

Nice work @daavoo! I really like how it achieves two important product goals: * Makes DVC easier and more flexible for complex configuration. * Makes it easier to track final...

@daavoo I haven't had a chance to look at your responses yet, but @dmpetrov asked why Hydra is configured in `.dvc/config` instead of at the pipeline/stage level inside `dvc.yaml`?

Pros and cons of the `dvc.yaml` approach: **Pros** * More granular control over where and how to use Hydra. For example, I could use the same hydra config_dir in two...

For future reference, I set up https://github.com/dberenbaum/complex_config_example when I was testing this out 😅 (edit: main branch uses current dvc functionality, hydra branch uses this PR)

> * By default, composed config will be dumped to `params.yaml`. > `config.hydra.output_file` is now optional and can be used for changing the default behavior. > Contents of `output_file` will...

> * `config.hydra.config_dir` is the config option that enables/disables the hydra compose and dump behavior. Sorry to come back to this so late, but I'm still slightly confused. `hydra.config_dir` acts...

@iterative/dvc Could someone review please?

I think the original issue is about tracking the expanded environment variable value as a dependency, so that `/home/ubuntu/project/build/virtualenv/bin/rasa` becomes a dependency, and if another user sets `RASA_PATH=/Users/user/project/build/virtualenv/bin/rasa`, then it...

@stephanrb3 How would you use the feature to gather info on the branch or make additional commits? Do you have some example you could share?

Yes, either `update` or `status` flags would make sense. We don't want users to have to recreate the whole `import-url` to find out whether the source has changed.