Remember configuration flags

[ivan-m]

If I want to build a package on my local machine with certain Cabal flags enabled/disabled, is there any way of using stack that would let me set this once and then not have to remember to do so each time?

For example, using cabal-install I could do cabal configure --flags=foo and then just run cabal build any time I wanted to try building it without having to specify the flag again.

However, the only thing I can see to do with stack is to always do stack build --flag package=foo (and there doesn't seem to be any way of enabling/disabling flags for use with stack ghci).

[mgsloan]

If I want to build a package on my local machine with certain Cabal flags enabled/disabled, is there any way of using stack that would let me set this once and then not have to remember to do so each time?

IIRC, this is an intentional design decision of stack, to eliminate statefullness that can get in the way of straightforward build determinism and scriptability.

I agree that it's unpleasant when you accidentally forget a flag and it unregisters a bunch of stuff as a result.. Lets discuss current approaches / whether something should be added to stack for this.

However, the only thing I can see to do with stack is to always do stack build --flag package=foo

How about the flags field of stack.yaml?

I usually handle this circumstance by editing my stack.yaml (see #846). If you don't want to deal with having working copy changes, you can copy stack.yaml to a different path and either pass --stack-yaml or set the STACK_YAML environment variable.

Another approach would be to handle this in an external wrapper script that handles generating your stack.yaml - see the discussion here.

and there doesn't seem to be any way of enabling/disabling flags for use with stack ghci

As of 0.1.8, flags do work with stack ghci. Maybe you're running into #1419, where CPP flags aren't passed in to ghci? A fix for that is in the development version.

[ivan-m]

I know about the flags field; the problem is that on my machine I'm unable to build a dependency (due to a C++ library that I can't seem to link on OSX) so I'm using a flag to disable that part of the codepath; however, I can't specify that in the stack.yaml file as everywhere else (including our deployment setup) wants/needs that flag enabled.

I see that using either --stack-yaml or STACK_YAML to point to an alternative one would fix it for me (though IIUC that would still require either an option or else a global variable that affects only one project and would cause problems with everything else); but that means I suffer not having changes to the real stack.yaml being propagated to my local version.

Would it be feasible to have a flags.yaml file or some such just to specify these kind of machine-specific flags that overrides/augments stack.yaml?

(As for the stack ghci bit; turns out that I missed that stack upgrade put the newer version somewhere that wasn't on my $PATH so the option wasn't available on the old version I kept using.)

[mgsloan]

Yeah, having some way to override / extend a stack.yaml could be nice. But I think the consensus so far is to keep it simple and not implement such a mechanism: #1375

[ivan-m]

Fair enough.

I'm currently working around it by having local variables in Emacs to add the option to calls to stack ghci and stack build (in case anyone happens to be searching why the obvious solution doesn't work and finds this: you can't have space-separated options so make the --flags a separate argument from the actual flag-setting) and just have to remember to do this myself if I end up building it in the terminal for some reason.