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

Add an option to not panic on value*of() of non valid arguments #3621

Closed
2 tasks done
lu-zero opened this issue Apr 10, 2022 · 8 comments · Fixed by #3732
Closed
2 tasks done

Add an option to not panic on value*of() of non valid arguments #3621

lu-zero opened this issue Apr 10, 2022 · 8 comments · Fixed by #3732
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing

Comments

@lu-zero
Copy link
Contributor

lu-zero commented Apr 10, 2022

Please complete the following tasks

Clap Version

clap-3.1.8

Describe your use case

The cargo feature exposes is_valid() as workaround but it makes quite cumbersome to deal with code that has similar needs.

Describe the solution you'd like

Adding a setting to simply return None would spare quite a bit of boilerplate.

Alternatives, if applicable

Make so the cargo feature re-enable the former behavior.

Additional Context

No response

@lu-zero lu-zero added the C-enhancement Category: Raise on the bar on expectations label Apr 10, 2022
@epage
Copy link
Member

epage commented Apr 11, 2022

It'd help if you explained why you don't want arguments validated.

Make so the cargo feature re-enable the former behavior.

What does the cargo feature have to do with this request?

@lu-zero
Copy link
Contributor Author

lu-zero commented Apr 11, 2022

The use case is the same as cargo's, the cargo feature is already there to accommodate the needs of cargo.

@epage
Copy link
Member

epage commented Apr 11, 2022

The use case is the same as cargo's

Can you go into more detail. What are you doing, how, and why. Understanding what people are trying to accomplish with a request is important for shaping features.

the cargo feature is already there to accommodate the needs of cargo.

The cargo feature is for not for the needs of cargo. In fact, cargo doesn't enable it.

From the README

cargo: Turns on macros that read values from CARGO_* environment variables.

Example of something relying on this feature: https://docs.rs/clap/latest/clap/macro.command.html

@lu-zero
Copy link
Contributor Author

lu-zero commented Apr 11, 2022

The use case is the same as cargo's

Can you go into more detail. What are you doing, how, and why. Understanding what people are trying to accomplish with a request is important for shaping features.

cargo has multiple applets and some codepaths are common and they rely now on is_valid() to simulate what previously was simply the use of value_of() and managing the None path.

the cargo feature is already there to accommodate the needs of cargo.

The cargo feature is for not for the needs of cargo. In fact, cargo doesn't enable it.

From the README

Sorry, I meant treat it as the is_valid*() set of functions that cargo uses.

@epage
Copy link
Member

epage commented Apr 11, 2022

cargo has multiple applets and some codepaths are common and they rely now on is_valid() to simulate what previously was simply the use of value_of() and managing the None path.

Yes, I'm the one who ported cargo to clap3 and added is_valid for that purpose.

I'm taking it from your comments that you are depending directly on cargo and are re-using its flag definitions and flag reading?

@lu-zero
Copy link
Contributor Author

lu-zero commented Apr 11, 2022

yes.

@epage
Copy link
Member

epage commented Apr 11, 2022

Huh, for some reason I created an issue for finding a longer term solution for cargo but I can't find it. Guess we'll use this for tracking that then.

@epage epage added A-parsing Area: Parser's logic and needs it changed somehow. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Apr 11, 2022
@lu-zero
Copy link
Contributor Author

lu-zero commented Apr 11, 2022

Thank you :)

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-design Status: Waiting on user-facing design to be resolved before implementing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants