Allow global options both before and after command

[snoyberg]

I believe this is a regression, since it seemed to work properly before. See #505. Both of the following should work, but currently only the latter does. This may be an issue in optparse-simple:

stack build --resolver lts-2.16
stack --resolver lts-2.16 build

Assigning to @manny-fp, but pinging @chrisdone who may have a quick answer.

[DanBurton]

I thought it had been this way for a long time / always. (Global opts must
come before the command.)

On Sunday, July 5, 2015, Michael Snoyman notifications@github.com wrote:

I believe this is a regression, since it seemed to work properly before.
See #505 #505. Both of
the following should work, but currently only the latter does. This may be
an issue in optparse-simple:

stack build --resolver lts-2.16
stack --resolver lts-2.16 build

Assigning to @manny-fp https://github.com/manny-fp, but pinging
@chrisdone https://github.com/chrisdone who may have a quick answer.

—
Reply to this email directly or view it on GitHub
#519.

-- Dan Burton

[3noch]

I recall getting tripped up several times and needing to move --arch before the command, ever since that option was introduced. I think it's been this way for a while.

[borsboom]

I'm pretty sure it's been this way since the start, and it is normal behaviour for optparse-applicative. That said, it's really annoying and worth fixing.

[chrisdone]

Haven't rebuilt stack for a week, seems that --resolver is handled in both cases on my commit:

chris@retina:~/Packages/ace$ stack build --resolver lts-2.12
Downloading lts-2.12 build plan ...^Cuser interrupt
chris@retina:~/Packages/ace$ stack --resolver lts-2.12 build
Downloading lts-2.12 build plan ...^Cuser interrupt
chris@retina:~/Packages/ace$ stack --version
Version 0.1.1.0, Git revision 66ce026d5cf61d0d5e34dd2379f4096578ac8e33
chris@retina:~/Packages/ace$ 

So if this isn't working on master, it's a regression.

[chrisdone]

I'm pretty sure it's been this way since the start, and it is normal behaviour for optparse-applicative. That said, it's really annoying and worth fixing.

If that were true, stack build -v would never have worked (verbosity is a global flag).

[borsboom]

Using the just-released 0.1.2.0, both of the --resolver cases work for me:

$ stack build --resolver lts-2.16
data-default-class-0.0.1: configure
Prcryptohash-0.11.6: configure
Progress: 8/124user interrupt
$ stack --resolver lts-2.16 build
data-default-class-0.0.1: configure
PrProgress: 8/124user interrupt

What doesn't work is putting command-specific option before the subcommand. E.g.,

$ stack --no-optimizations build
Invalid option `--no-optimizations'

[k-bx]

Please, as part of this issue, make sure that stack build --help shows --resolver flag option.

[borsboom]

@k-bx Since --resolver is a global option, it appears in the output of stack --help. Global options are left out of the subcommand-specific help (they would overwhelm it). But perhaps adding a note to the subcommand-specific help mentioning to use stack --help to see the global options would be a nice addition.

[chrisdone]

What doesn't work is putting command-specific option before the subcommand.

Right, that part makes sense.

[k-bx]

@manny-fp yes, adding a note that there are more (global) options available would be nice. Would this need a separate issue?

[borsboom]

@k-bx Making a new issue means it is less likely to be missed, so I would encourage it :)

[phadej]

For me this didn't work ever: ```stack command --global-opt --command-opt`, i.e.

stack build --no-terminal --only-snapshot # doesn't work
stack build --only-snapshot --no-terminal # works
stack --no-terminal build --only-snapshot # works

That's why e.g. stack build -v works, I bet, stack build -v --only-snapshot didn't work ever.

[borsboom]

@k-bx Was just looking through the optparse-applicative issue tracker and came across this one filed by @chrisdone that's related to your request pcapriotti/optparse-applicative#138.

[k-bx]

Yeah, that one looks like what I was looking for, thanks.