dvc stage repro

A possible reason why some features might be underused is naming inconsistency.

• dvc stage {add,list}
• dvc repro
• dvc run

surely should be unified as dvc stage {add,list,run} or dvc stage {add,list,repro}? Could sanitising these CLI subcommands be part of the next major release?

[pmrowla]

The use case for dvc run is for a when a user wants to generate or modify a stage in dvc.yaml. This is redundant and confusing, which is why removing/deprecating it in favor of dvc stage add is preferred. The use case for dvc run is not for reproducing a single stage within an existing pipeline/dvc.yaml.

The one thing that dvc run does right now that dvc stage add does not, is that dvc run can actually execute the stage command once. This can be useful when generating stages because it makes DVC verify that all of the outputs you listed for the stage were actually generated, and that the command itself was executed properly (so run provides a sanity check/validation)

To fill this use case, dvc stage add just needs an extra flag to run the stage once, i.e dvc stage add --run as described in #5846

A) What are the underlying concepts? afaik it’s: 1. Pipelines, 2. Experiments B) does the commandline interface map 1:1 to the above concepts?

• dvc repro exists to do everything you have described in 1. Pipelines
• dvc exp run exists to do 2. Experiments.

This seems pretty clear-cut to me.

dvc stage ... exists solely to provide a CLI interface for adding/modifying/removing stages inside dvc.yaml files in the event that a user prefers using the CLI to do it instead of editing the yaml file themselves. It supplements both the “pipelines” and “experiments” use cases, since a user needs to generate dvc.yaml files in both cases.

IMO this is the same as dvc remote ... existing to add/remove/modify remote entries in a DVC configuration file, but dvc push/pull/fetch existing separate from dvc remote .... The remote commands are for configuration. push/pull/fetch are for filling the use case of “store and retrieve files to/from cloud storage”.

Likewise stage ... provide configuration (of dvc.yaml files). repro and exp run are for actually reproducing pipelines and conducting experiments.

[pmrowla]

I think this is mostly a duplicate of https://github.com/iterative/dvc/issues/5846