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

Allow global options both before and after command #519

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

Allow global options both before and after command #519

snoyberg opened this issue Jul 5, 2015 · 14 comments

Comments

@snoyberg
Copy link
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
Copy link
Contributor

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
Copy link
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
Copy link
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
Copy link
Member

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
Copy link
Member

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
Copy link
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
Copy link
Contributor

k-bx commented Jul 6, 2015

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

@borsboom
Copy link
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
Copy link
Member

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

Right, that part makes sense.

@k-bx
Copy link
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
Copy link
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
Copy link
Collaborator

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
Copy link
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
Copy link
Contributor

k-bx commented Jul 7, 2015 via email

@borsboom borsboom assigned borsboom and unassigned drwebb Oct 26, 2015
mgsloan referenced this issue in harendra-kumar/stack Jan 27, 2016
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
Projects
None yet
Development

No branches or pull requests

8 participants