Consistent '--*-options' options

[borsboom]

Currently there are a few different conventions in use for stack options that specify options to pass to external programs. These should be made consistent, preferably sharing an optparse-applicative Parser between them. I'm thinking they should all allow two different ways:

--*-option: pass a single argument, which may contain spaces.
--*-options: pass multiple space-separated arguments (parsed with argsParser)

It should be possible to pass both of these multiple times, in which case the options are concatenated in the order given.

In some cases, we also specify options in YAML configuration files. The configuration field should be named *-options, and should contain a YAML sequence. Sequences are concatenated when cascading configuration files (and any additional options from the command-line are concatenated after those from the configuration file).

(motivated by #601)

[DanBurton]

+1 I generally agree with everything proposed here.

On Tuesday, July 21, 2015, Emanuel Borsboom notifications@github.com
wrote:

Currently there are a few different conventions in use for stack options
that specify options to pass to external programs. These should be made
consistent, preferably sharing an optparse-applicative between them. I'm
thinking they should all allow two different ways:

---option: pass a single argument, which may contain spaces.
---options: pass multiple space-separated arguments (parsed with
argsParser

stack/src/Data/Attoparsec/Args.hs

Line 38 in e328d63

argsParser :: EscapingMode -> Parser Text [String]

It should be possible to pass both of these multiple times, in which case
the options are concatenated in the order given.

In some cases, we also specify options in YAML configuration files. The
configuration field should be named *-options, and should contain a YAML
sequence. Sequences are concatenated when cascading configuration files
(and any additional options from the command-line are concatenated after
those from the configuration file).

(motivated by #601 #601
)

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

-- Dan Burton

[mgsloan]

RyanGIScott just mentioned in #haskell-stack that he'd like a way to pass options to ghc-pkg, so we should be sure this covers that use case. It's to work around this issue gtk2hs/gtk2hs#139

[mgsloan]

Lets make sure this handles ghcjs-boot-options

[mpilgrem]

With Stack 2.15.1, the state of affairs is:

• build: --ghc-options
• build: --PROG-option
• build: --haddock-arguments
• build: --ta, --test-arguments
• build: --ba, --benchmark-arguments
• docker run: --docker-run-args
• --nix-shell-options

There is also:

• hoogle: -- ARGUMENT(S)
• ghc: -- ARGUMENT(S)
• runghc: -- ARGUMENT(S)