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

Environment variable name aliases #5447

Open
2 tasks done
Aeron opened this issue Apr 8, 2024 · 1 comment
Open
2 tasks done

Environment variable name aliases #5447

Aeron opened this issue Apr 8, 2024 · 1 comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-waiting-on-decision Status: Waiting on a go/no-go before implementing

Comments

@Aeron
Copy link

Aeron commented Apr 8, 2024

Please complete the following tasks

Clap Version

4.4.8

Describe your use case

Clap already supports aliases for short and long argument names, which is superb, especially for keeping backward compatibility. Yet environment variables lack this feature that can be useful in all the same cases.

For example, if my CLI changes one of its arguments’ name, I can keep compatibility with short_alias and alias functions and derive parameters. But if such an argument has an environment variable assigned, I either need to keep the name that became inconsistent with the argument name or introduce a breaking CLI change.

For another case, the same will be true if I no longer need separate arguments for something that now can be treated as one value, so I need to merge two argument names. The short_aliases and aliases will cover it great. But environment variables will hold me back from doing so.

Describe the solution you'd like

It’d be nice to have the same alias options for environment variables, like env_aliases and env_alias—a super-similar implementation to what argument names have.

Alternatives, if applicable

No response

Additional Context

I can prepare a PR if there are no objections, considerations, or pitfalls I’m missing. Maybe I overlooked something, or there are some limitations.

@Aeron Aeron added the C-enhancement Category: Raise on the bar on expectations label Apr 8, 2024
@epage epage added S-waiting-on-decision Status: Waiting on a go/no-go before implementing A-parsing Area: Parser's logic and needs it changed somehow. labels Apr 9, 2024
@epage
Copy link
Member

epage commented Apr 9, 2024

I can prepare a PR if there are no objections, considerations, or pitfalls I’m missing. Maybe I overlooked something, or there are some limitations.

I appreciate the willingness. My main hesitation is just around figuring out where the line is for what feature we provide. Sometimes providing features that overlap just enough with out use case lead people wanting a lot more like #2763. Each feature also has an impact, on discoverability, on binary size (#2038), and and build-times (#1365). This is behind an env feature which helps but even that has its downsides.

So I think I want to sit on this a bit, let my thoughts settle on this a bit and to see what other input comes along.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-waiting-on-decision Status: Waiting on a go/no-go before implementing
Projects
None yet
Development

No branches or pull requests

2 participants