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

Ordering of options should not matter #1531

harendra-kumar opened this issue Dec 17, 2015 · 2 comments

Ordering of options should not matter #1531

harendra-kumar opened this issue Dec 17, 2015 · 2 comments


Copy link

All of the following behave in the same way. Perhaps it silently ignores whatever follows --solver and parses as a valid option.

stack init --solver
stack init --solver --resolver ghc-7.8.4
stack init --solver --compiler ghc-7.8.4

But if I change the order it spits out an error message:

cueball:/vol/hosts/cueball/workspace/halberd$ stack init --resolver ghc-7.8.4 --solver
Usage: stack init ([--solver] | [--resolver RESOLVER] | [--prefer-lts] |
                  [--prefer-nightly]) [--force] [--ignore-subdirs]
                  [--nix-shell-file FILEPATH] [--help]
  Initialize a stack project based on one or more cabal packages

Though it still does not say what's wrong with it. I found #601 and #1461 raised about this already.

Copy link

This is a weird case because there is a global --resolver argument and a stack init subcommand-specific --resolver option. Due to this ambiguity, optparse-applicative would select differently depending on the position of the argument. Now I've made a change so that the global --resolver is disabled if it comes after stack init so there is no longer ambiguity and the error is displayed with either ordering.

Copy link
Collaborator Author

I opened #1588 to get rid of the stack init resolver parsing.

harendra-kumar added a commit to harendra-kumar/stack that referenced this issue Jan 19, 2016
Now that there is no local --resolver option for stack init we can allow the
global option to be used in subcommand context.

This was disabled by the fix for commercialhaskell#1531. I have reverted the init specific fix for
that but kept the overall mechanism for any future use.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants