MWCommand captures the arguments in the order they were passed in at the command line, for use in processing pipelines, which are sensitive to this order.
However, when an equal sign is used to separate the flag & value on the command line, e.g. --foo=bar, the two are captured as one list item, and this breaks the pipeline processing code.
The algorithm to split these is not simple, at least because of:
- "flag" options (which do not take a value on the command line).
- short unix-style options, which should include everything after the short option flag, including an equal sign if present (e.g. -c=myfile.py should parse to become ["-c", "=myfile.py"].
I think the best solution is to use the click parser to parse the args. It returns a dict of option name-value pairs (if the option accepts multiple values then the value will be a tuple of values), and a list of Parameter objects that describe the parameter (which is an Option or Argument) that is mostly in the same order as the command line.
From these two things, an approximate reconstruction of the command line call can be created. The only considerable differences are
- if an option has multiple option flags, it is not easy to determine which one was used. (However, all downstream code that uses the flags should be able to use any of the ones used by the function, so it should be fine to just pick one.)
- in the list of Parameter objects, Options come first and Arguments are last. The order of Options is preserved, as is the order of Arguments.