Subcommand-specific -v flag shadows the global one

We register -v on subcommands (such as lock create), but we also register it globally. However argparse returns the global args and subcommand args in a single Namespace object, and in that object the value from the subcommand wins, and so the global value is hidden.

In other words, in pex -vvv lock create -vvvvv .... the subcommand value (verbosity=5) is the one available in the Namespace object returned by parse_args(), and the global value (verbosity=3) is not available anywhere. This is true even if no explicit arg is provided for the subcommand. The subcommand arg’s default (verbosity=0) overwrites the global value.

This is confusing to users, because pex -vvv lock create doesn’t fail, it just silently ignores that value. Pants, in fact, made this mistake.

We work around this in Pants here: https://github.com/pantsbuild/pants/pull/15243 but should fix at the Pex level as well.

One option is to not register the verbosity flag globally. Another, possibly simpler, is to only register it globally and not register it on the subcommands. In either case, there is the following consequence: the flag cannot appear in that position. I.e., either pex -vvv lock create ... will fail or pex lock create -vvv ... will fail, respectively.

A third, probably best, option is to register the global verbosity under a different dest. Then both will be available in the Namespace object. We then just have to decide what the effective verbosity should be if both are specified.

[benjyw]

As you may have guessed, this affects all the global options. Basically registering them in global position, as we do today, has no practical effect and the args are silently ignored, if a subcommand is encountered.

[jsirois]

Hrm. Yeah, I was confused by subcommands in argparse and I think I still am. Trying to page this in, but the path you’re pushing seems like the right way to fix things for now at the very least.