Skip to content

dvc: option/param consistency #3422

Closed
Closed

Description

One thing I think we should not do as Git is to have inconsistent options (and API parameters) (e.g. git branch -D vs. git remote remove). Better consistency in command/subcommand usage decrease the learning curve and makes for an enjoyable CLI (heroku is a good example).

Here's the ones I've found after briefly checking all refs:

  • add/run/import -f (DVC-file name) checkout/init/etc -f (force)
  • get-url/import-url [out] vs. get/import --out vs move dst
  • gc --projects REPOS – is it project or repo?
  • add targets, metric diffs --targets vs. metrics ... path (or path API param)
    UPDATE: and now list url target? See address dvc list review from Jorge #3381 (comment)
  • --show-json vs --show-hash/--show-url (different meaning of "show")
  • --show-json vs --ascii
  • Order of standard -hqv options in help output. Usually they're shown first as [-h] [-q | -v] but not always, for example remote ... [-h] [--global] [--system] [--local] [-q | -v]
  • config name [value] vs dvc remote modify name option [value]
  • maybe remove -p (purge) vs repro -p (pipeline)

This may seem like a polishing thing but I think it's actually best to address sooner than later, before too many users learn the existing options which makes it harder to change them. In any case, renamed options should be left hidden for some time, for legacy/scripting support.


Other misc. comments:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    enhancementEnhances DVCuiuser interface / interaction

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions