Ordering of options should not matter

[harendra-kumar]

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.

[borsboom]

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.

[harendra-kumar]

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