Consistent subcommand order

[jorgeorpinel]

Help output of commands with subcommands have a seemingly random order. I propose this (matches docs repo nav sidebar per iterative/dvc.org/pull/1110):

metrics: add, modify, show, diff, remove
pipeline: list, show
remote: add, default, modify, list, remove

I can probably send the PR too 🙂 lmk

[skshetry]

@jorgeorpinel, the order of the subcommands can be changed by changing the order of the add_parser calls. However, it's easy to mess things up (eg: someone adds a subcommand, etc) and is fragile and hackish. We could extend HelpFormatter to sort those subcommands, but, I don't think it's worth investing time in doing this at all.

[jorgeorpinel]

Maybe not from a technical point of view but from a user experience perspective, these details can make a significant difference.

i.e. let't put ourselves in the shoes of the user, not of the developer 🙂

[efiop]

Changing the order in the code is the only sane way to go here. And it is extremely simple to create a PR for it. @jorgeorpinel Please feel free to adjust it to your liking.

[efiop]

But as @skshetry mentioned, we provide no guarantees that we won't mess up the order in the future, because it is extremely easy to do that. So maybe not worth bothering at all. We have it sorted in docs - great, but in cli user never sees help for those together so won't ever notice the inconsistency. Your call @jorgeorpinel

[jorgeorpinel]

Looks like I have time for this now yay (will planning to include it in #3626).

• I also noticed the order of the options in each command help output comes from the order of each parser.add_argument( call. In docs we reordered the options arbitrarily according to which ones we think are more common or important. It would be nice to also match these... But probably for a separate issue UPDATE: Extracted to Consistent cmd option order? #3642