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

Activity

1. davidism commented on Feb 25, 2022

   

   davidism

   on Feb 25, 2022

   Last edited by davidism

   Member

   More actions

   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.
2. kdeldycke commented on Apr 2, 2023

   

   kdeldycke

   on Apr 2, 2023

   Collaborator

   More actions

   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
3. kdeldycke

   added a commit that references this issue on Apr 2, 2023

   Add reference to pallets/click#1279.

   c96a5db
4. Rowlando13

   added

   f:context

   on Jan 6, 2025
5. kdeldycke

   added

   parsingParsing, parameters, commands, chaining, contextParsing, parameters, commands, chaining, context

   and removed

   f:context

   on Aug 8, 2026