Repository navigation
Missing auto-generated environment variables in help screen & case-sensitivity #2483
Description
Here is a simple CLI that mixes auto-generated and multiple environment variables:
from click import command, echo, option, pass_context
@command(context_settings={"auto_envvar_prefix": "yo", "show_default": True})
@option("--flag/--no-flag", envvar=["FlAg", "sUper"], show_envvar=True)
@pass_context
def my_cli(ctx, flag):
echo(f"Flag value: {flag}")
if __name__ == "__main__":
my_cli()This produces the following help screen:
$ python ./multiple_envvars.py --help
Usage: multiple_envvars.py [OPTIONS]
Options:
--flag / --no-flag [env var: FlAg, sUper; default: no-flag]
--help Show this message and exit.
Now let's try a couple of different envvars:
$ FlAg=1 python ./multiple_envvars.py
Flag value: True
$ FlAg=0 python ./multiple_envvars.py
Flag value: False
$ sUper=1 python ./multiple_envvars.py
Flag value: True
$ sUper=0 python ./multiple_envvars.py
Flag value: False
$ yo_FLAG=1 python ./multiple_envvars.py
Flag value: False
$ YO_FLAG=1 python ./multiple_envvars.py
Flag value: True
$ YO_FLAG=0 python ./multiple_envvars.py
Flag value: False
The surprise here is the discovery process of the auto-generated YO_FLAG. I expected it to respect the case-sensitivity of others. but everything auto-generated is uppercased.
So I wonder if we should enforce upper-casing all env vars, whatever their source.
And additionally, shouldn't we add the auto-generated YO_FLAG to the help screen to improve discoverability?
For reference, I ran these test on macOS / zsh, and with the latest click 8.3.1.
Activity
Add new populate_auto_envvars parameter to add missing auto-generated
kdeldycke commentedon Apr 7, 2023
Things are a little bit messier than I initially expected.
For instance, if I register explicitly the
yo_FLAGas an environment variable on the option, it is properly recognised with its own particular mixed-case. Which highlight the difference of treatment between registered envvar and auto-generated envvar.I currently mapped all these cases and mismatches on a test case here: https://github.com/kdeldycke/click-extra/blob/48f980b0d6fb1e7ddb914fe03f34d3460c8ef0ca/click_extra/tests/test_parameters.py#L62-L98
I'll continue experimenting with this in my Click Extra project and try to fix this over there.
davidism commentedon Apr 7, 2023
Environment variables are case sensistive except on Windows. Traditionally, variables are all uppercase, lowercase is usually only seen inside shell scripts. I feel like you're overthinking something here, there's nothing to fix regarding case.