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

Emit warnings for mistyped options #1860

Closed
MikeMcQuaid opened this issue Jan 16, 2017 · 13 comments
Closed

Emit warnings for mistyped options #1860

MikeMcQuaid opened this issue Jan 16, 2017 · 13 comments
Assignees
Labels
features New features in progress Maintainers are working on this outdated PR was locked due to age

Comments

@MikeMcQuaid
Copy link
Member

e.g. brew cleanup --hlep should refuse to run rather than silently ignoring the --hlep argument. This will likely require implementing a new DSL for Homebrew commands that lists all the possible arguments (where currently just ARGV.include? is used).

@GauthamGoli
Copy link
Contributor

Why can't we use this, instead of implementing a new DSL for parsing options?
https://docs.ruby-lang.org/en/2.1.0/OptionParser.html

@MikeMcQuaid
Copy link
Member Author

@GauthamGoli We could use that but it wouldn't solve the problem by itself. The issue is that ARGV.include? is used throughout the codebase as global state. This is solveable with or without a new option parser.

@Qchmqs
Copy link

Qchmqs commented Jan 29, 2017

the way it is now, those are hardcoded, can we extract them into a yaml, and try to apply fuzzy search first ? i feel like this will prove slow

@MikeMcQuaid
Copy link
Member Author

@Qchmqs Rather than a YAML we'd use a command DSL but yes, this might enable fuzzy search.

@lwe
Copy link
Contributor

lwe commented Mar 12, 2017

Another simple solution could be to create an ARGV.whitelist!(%w{--foobar --help}) in the commands that checks all args and raises on unknown arguments found. This approach would of course not work for install, but for other commands it would work very well. Biggest downside being that there is a large disconnect between actual place where the arg is used (could be anywhere in any file) vs. where the known arguments are enforced. It still relies on globals and starts adding more dependency to ARGV.

A command/arg DSL would of course solve this problem, but this would be a rather large refactoring and there are about 500 call sites that use that global variable ARGV. First I think it would require changes that ARGV is passed as argument, rather than used as a global variable, before a command DSL can be implemented.

@MikeMcQuaid
Copy link
Member Author

@lwe Agreed that the command/arg DSL would be the longer-term solution; I think that's probably the best thing to push towards at this point.

@apjanke
Copy link
Contributor

apjanke commented Jun 19, 2017

There's no work-in-progress on this at #2420.

@MikeMcQuaid MikeMcQuaid added in progress Maintainers are working on this and removed help wanted We want help addressing this labels Jun 19, 2017
@RandomDSdevel
Copy link
Contributor

RandomDSdevel commented Jun 19, 2017

@apjanke: Um, don't you mean something more along the lines of, "There's some now/new work in progress on this at #2420."…?

@apjanke
Copy link
Contributor

apjanke commented Jun 20, 2017

Uh, yes. I meant "now". Sorry.

@RandomDSdevel
Copy link
Contributor

@apjanke: Don't worry, it's cool. We all make typographical mistakes at some time or another. (Now, back to lurking…)

@MikeMcQuaid
Copy link
Member Author

This is done 🎉! Thanks to @GauthamGoli for the vast majority of the hard work here and designing such great APIs to use 👏

@alyssais
Copy link
Contributor

Popping in from Homebrew retirement since I was still subscribed to the issue to say: congratulations @GauthamGoli – what an amazing achievement. I didn't think this issue would ever be solved, and it looks like it did indeed take a huge amount of work. Wonderful stuff.

@apjanke
Copy link
Contributor

apjanke commented Feb 2, 2019

Hear, hear! This is a big win, IMHO. Congratulations @GauthamGoli!

I've tried out the new changes and it's already caught me out for inadvertently using a bogus option on one of my own formulae. Thanks for getting this in!

@lock lock bot added the outdated PR was locked due to age label Mar 4, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
features New features in progress Maintainers are working on this outdated PR was locked due to age
Projects
None yet
Development

No branches or pull requests

7 participants