parsing: Support dict unpacking in cmd.

[daavoo]

Allow to use dictionaries as values for template interpolation but only inside the cmd key.

Given the following params.yaml and dvc.yaml:

# params.yaml
dict:
  foo: foo
  bar: bar

# dvc.yaml
stages:
  stage1:
    cmd: python script.py ${dict}

The dictionary will be unpacked with the following syntax:

# dvc.yaml
stages:
  stage1:
    cmd: python script.py --foo foo --bar bar

Closes #6107

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

[skshetry]

Any recent motivations for this? 🙂

[daavoo]

Any recent motivations for this? 🙂

When exploring how to better integrate dvc params with ML frameworks, this showed as low-hanging fruit for some frameworks like Yolov5 (linked issue), HuggingFace , PyTorch Lightning, etc.
In addition, the default syntax is good enough for custom training scripts using simple argparse and having more flexibility of configuring cmd calls of CLI tools without having to edit dvc.yaml for each iteration (adding/removing argument)

[karajan1001]

This only works for argparse.BooleanOptionalAction not for store_true/false. Maybe need some better way to handle this?

[daavoo]

The same issue about different options, as commented below #7907 (comment)

Which option do you think we should consider as the most appropriate default?

Note that this can be used for things beyond argparse, for example you can use the interpolation to pass flags to arbitrary executables that you call inside cmd

[daavoo]

Added config.parsing.list with store_true and boolean_optional .

Not sure about store_false because the interaction with dvc params would look kind of strange, IMO

[karajan1001]

I also have no idea about it.

[dberenbaum]

I think that's more than enough to support for now.

[karajan1001]

> import argparse
> parser = argparse.ArgumentParser()
> parser.add_argument('--foo', nargs='*')
> parser.parse_args('--foo x y'.split())
Namespace(foo=['x', 'y'])

> parser.parse_args('--foo x --foo y'.split())
Namespace(foo=['y'])

Looks like setting arguments for multi times will overwrite the previous one.

[daavoo]

The idea was to cover the action='append' mode:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', action='append')
>>> parser.parse_args('--foo 1 --foo 2'.split())
Namespace(foo=['1', '2'])

Maybe it's a matter of clearly stating it in the docs.
Ideally, we should support all options but I am not sure how to do it. We could add a bunch of config options or just allow users to register a custom to_str method for interpolation.

[dberenbaum]

Let's pick one behavior for now. Is it possible to see which one is more widely used in existing ML CLIs? I would guess the nargs --foo 1 2 behavior is more common, even though I find the explicit append behavior easier to read.

[daavoo]

Added config.parsing.list with nargs and append options. It doesn't look that bad to have the options.

[skshetry]

Just noticed this, it's a bad idea to make dvc.yaml parsing conditional, it should be self-contained.

[karajan1001]

1. Maybe we only need to test two different conditions? The None can be tested through some other method (Test if the default value is set correctly)?
2. Because these two configurations are independent, maybe we can test them in an (I'm not sure how to describe it) instead of using a product. ["a1b1", "a2b2"] instead of ["a1", "a2"] x ["b1", "b2"].
   The two suggestions above can reduce the amount of the test from 9 to 2.

[daavoo]

I updated it to 3 test cases (["a1b1", "a2b2"]). I still included the default in the same test, not sure if it's worth it to separate it as the body of the test would be the same

[karajan1001]

LGTM for the most part, another concern is that the two new configurations still can't solve all of the problems as two different types of arg might exist in one command.

[daavoo]

another concern is that the two new configurations still can't solve all of the problems as two different types of arg might exist in one command.

Indeed. There are many unsolved issues but the idea for this initial P.R. is to cover basic scenarios to don't overcomplicate the logic until users request for specific issues