Allow more command-line options to be specified within stack.yaml

[drvink]

Unless I'm missing something, it doesn't seem to be able to set defaults within a stack.yaml for things like --library-profiling, --haddock, etc. Furthermore, some flags that were available in cabal install are gone entirely (like --enable-executable-stripping, just as a random example), and it's not obvious whether there's any workarounds available.

[drwebb]

@drvink You could make a PR with additional fields you think are good to have in the stack.yaml file. You'll want to start by editing the Config datatype in src/Stack/Types/Config.hs

Some flags present in cabal-install aren't present in stack, which is because we haven't made it a design goal to replicate every functionality. Starting other issues are good for tracking adding these.

[lukexi]

As mentioned in #757, it would be great to have the modify-code-page flag available in a config file as it's generally something one needs to set persistently.

[mgsloan]

How about having a field called configure-options, which has the same format as ghc-options? This would specify per-package options to pass when configuring packages.

[mgsloan]

@snoyberg @borsboom Are y'all on board with "configure-options"? See also the discussion here: #1341 (comment)

I wish there was something better for doing this with snapshot dependencies, but that seems like a rather tricky problem to solve.

[borsboom]

@mgsloan I think you're mis-reading this issue. This one is about taking existing options (e.g., the various build options) and making it possible to set defaults in stack.yaml. Adding additional new options (like configure-options) should be a separate issue.

(edit: I see the original request included both, but @drwebb's comment limited the scope and suggested separate issues for new options)

[borsboom]

@drwebb, I think you're working on this issue?

[borsboom]

Discussion about adding cabal configure options: #1438

[mgsloan]

I'm imagining this looking like:

stack-options: --library-profiling

[charles-cooper]

@mgsloan Could that result in redundant ways to set command line options? E.g.

nix:
  enable: true

vs

stack-options: --nix

[mgsloan]

Yes. stack-options would override these. We might even consider deprecating some of the less used stack.yaml options. I kinda like just having CLI for the less common things, as then there's one thing to learn instead of potentially 2 (though I think we do a good job of keeping the naming consistent between the two).

I think the implementation should look like the following:

• Parse the arguments, to get the path to the stack.yaml if specified there.
• If the stack-options field is specified in stack.yaml, then prepend it to the CLI arguments, and reparse

This may get rather hairy, I know the code for this stuff is surprisingly complicated, due to running in interpreter mode and providing decent error messages.

It may actually make sense to use yaml lists for the options. While this looks a little weird, it's better than implementing bash argument parsing:

stack-options:
- "--library-profiling"

Alternatively, we could be sure to make it possible to set every CLI option as a stack.yaml option. That seems a bit overkill to me, though.

[charles-cooper]

Basically, one way or another reifying BuildOpts (https://github.com/commercialhaskell/stack/blob/master/src/Stack/Types/Build.hs#L423) and ConfigMonoid (https://github.com/commercialhaskell/stack/blob/master/src/Stack/Types/Config.hs#L732)

I don't think people mind learning two sets of options (I certainly don't). It's just confusing when options which affect the build plan aren't available in stack.yaml.

[mgsloan]

Right, it is certainly an option to just do all the plumbing to get every CLI option available from stack.yaml. One issue is that the options parsing does do some things a little bit fancier than straight parsing - https://github.com/commercialhaskell/stack/blob/master/src/Stack/Options.hs#L84 . In order to support the --profile and --trace flags within stack.yaml, we'd need to move this logic elsewhere.

I think it makes sense to make a distinction between options that we want to be part of the project's configuration (part of the repo), and things that are more like development time configuration (now I'm profiling, now I want coverage info, etc).

So, the purpose of this stack-options: field would be to allow you to specify development time configuration options in such a way that you don't need to remember to add them to every invocation. We could even have it say "Warning: Your stack.yaml uses the stack-options field. You probably shouldn't check it in to your repository, as it's intended to be used for options related to a particular development task".

[mgsloan]

In other words, we actually want to discourage people from writing a stack.yaml file that enables profiling (and perhaps make it a little less convenient than having an actual field for it), but we do want to allow it.

[borsboom]

Ideally, this could go in a "local options" file (e.g. stack.local.yaml or something), since it shouldn't be something that would get committed to version control. Having generalized stack.yaml inheritance would be nice for this (e.g. be able to set any stack.yaml option as overrides in the local file).

[chrisdone]

This thread seems to have stalled. Poke!

With the upcoming stack hoogle, always generating haddocks (#880) is a very desirable property to stick in the global stack.yaml. I'm not convinced we should be considering the command-line options to stack to be the core interface to stack; it's just one UI and the config file is another.

We've already got this in our ~/.stack/config.yaml:

templates:
  params:
    author-email: chrisdone@gmail.com
    author-name: Chris Done
    category: Web
    copyright: 2015 Chris Done
    github-username: chrisdone

And the nix thing someone already mentioned:

nix:
 enable: True

Why not also:

documentation: 
  enable: True
profiling: 
  enable: True

etc. and call it a day?

[rpglover64]

This already exists (though IIRC is undocumented):

build:
  haddock: true

@chrisdone, does that work for you for now?

[chrisdone]

It does! 👏😄 I'll update the other issue.

[borsboom]

I wonder if we can close this issue. Or are there more options we should add than were done by making basically all build arguments settable? Maybe would be better to have more specific issues than this rather vague one.

[drvink]

As the original guilty party for filing this issue, I'm OK with it being closed as long as it's now more or less possible to stash arguments in a persisted config somewhere rather than having to specify them on the command line for every build.

[mgsloan]

SGTM, lets open issues for specific CLI things that ought to be settable via configuration.