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

Allow global options both before and after command #519

Closed
snoyberg opened this Issue Jul 5, 2015 · 14 comments

Comments

Projects
None yet
8 participants
@snoyberg
Contributor

snoyberg commented Jul 5, 2015

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.

@snoyberg snoyberg added this to the 0.3.0.0 milestone Jul 5, 2015

@DanBurton

This comment has been minimized.

Contributor

DanBurton commented Jul 5, 2015

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

This comment has been minimized.

Member

3noch commented Jul 5, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 5, 2015

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

This comment has been minimized.

Member

chrisdone commented Jul 6, 2015

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

This comment has been minimized.

Member

chrisdone commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

This comment has been minimized.

Contributor

k-bx commented Jul 6, 2015

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

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

@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

This comment has been minimized.

Member

chrisdone commented Jul 6, 2015

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

Right, that part makes sense.

@k-bx

This comment has been minimized.

Contributor

k-bx commented Jul 6, 2015

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

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

@phadej

This comment has been minimized.

Contributor

phadej commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

@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

This comment has been minimized.

Contributor

k-bx commented Jul 7, 2015

@borsboom borsboom assigned borsboom and unassigned drwebb Oct 26, 2015

@borsboom borsboom closed this in b265f80 Oct 31, 2015

mgsloan referenced this issue in harendra-kumar/stack Jan 27, 2016

init: use global --resolver option
stack init now uses the global --resolver option instead of its own
implementation of the same.

This changes the CLI behavior: you will have to use
`stack --resolver lts-4.1 init` instead of `stack init --resolver lts-4.1`

Fixes commercialhaskell#1588
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment