provide access to a normalized list of args that will result in the same params

[graingert]

In pip-tools I want to be able to store the args that pip-compile was called with in its output. However I want to normalize the output so that syntactic arg changes are ignored.

Effectively, I want to be able to serialize a Context object into a list of args, such that all equivalent Context objects generate the same list of arg strings.

jazzband/pip-tools#788

[davidism]

I'd like to define exactly what this means. I can see how this might be possible, but what we actually reconstruct matters. Here's a format I think makes sense.

• Output all options before all arguments, in definition order instead of provided order, regardless of if interspersed arguments are allowed.
• If unknown options and/or extra arguments are allowed, output them at the end of the argument list.
• If the double dash switch is allowed, place it before the first argument that starts with an option prefix.
• If an option can be specified multiple times, group these repeats together, -a 1 -a 2 -a 3.
• Use a long option name if available, and the first such name if multiple are defined.
• Long option values are separated, --key value vs --key=value.
• Short option values are separated, -k value vs -kvalue.
• Flags are separated, -a -b vs -ab.
• Include options whose values were taken from a prompt or environment variable. We only know about prompts during processing, not later from the command callback.
• Do not include a value from a prompt if it was a hidden prompt, as that could cause sensitive information to be displayed.
• Exclude an option with the default value, unless the context's default map was used and different than the real default.
• Omit an option value, but not the option itself, if the option only optionally takes a value and the value matches the flag value.
• Use the name a subcommand was defined with instead a an alias it was provided as, unless the command is not actually registered with its defined name.

File and path types can be ambiguous. Should they be absolute, or relative to the current directory, or remain untouched? The resulting command can't be guaranteed to work either way. If it's always absolute, it breaks if the user really did mean "I'm going to run this command from multiple places and expect a file there". If it's always relative, it breaks if the user meant to refer to a specific file regardless of location and later runs the command somewhere else. If it's the original input, then both these things happen.

Parameters with custom types can't be guaranteed to output a usable value. We could add a ParamType.to_cli_value as the reverse of convert, and error if it's not implemented for a type. However, a parameter can also have a callback that's applied during processing after the type conversion, which can further change the value.

[kdeldycke]

I had a related issue a while back, as I was looking to introspect the normalized values of options, after Click applied all its cleaning operations. Unfortunately the process is quite complex and deeply embedded into the Click code path. Ideally I wanted to have a raw_args property somewhere on the Context so I could look at the cleaned options.

In the end I did just patched the make_context() method on Command to intercept and store the cleaned args in the Context: https://github.com/kdeldycke/click-extra/blob/ff863f46c50f0a042ef5a5166746eaee52a930f5/click_extra/commands.py#L157-L179

If you want to reuse my workaround, I made it available on my @extra_command() / @extra_group() decorators from my Click Extra project: https://kdeldycke.github.io/click-extra/commands.html#introspecting-parameters