Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing auto-generated environment variables in help screen & case-sensitivity #2483

Closed
kdeldycke opened this issue Apr 5, 2023 · 2 comments

Comments

@kdeldycke
Copy link
Contributor

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.

kdeldycke added a commit to kdeldycke/click-extra that referenced this issue Apr 5, 2023
@kdeldycke
Copy link
Contributor Author

Things are a little bit messier than I initially expected.

For instance, if I register explicitly the yo_FLAG as 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
Copy link
Member

davidism commented 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants