Conditional inclusion of packages:

[hamishmack]

Is there a way to do this? For instance we have this in leksah.cabal:

if os(osx)
    build-depends:
        gi-gtkosxapplication >=0.2.0.12 && <0.3

But if we want to include this in packages: we get:

No .cabal file found in directory /home/jpmoresmau/Documents/leksah/haskell-gi/bindings/GtkosxApplication/

In this case it is because haskell-gi cannot generate the package on Linux.

Could we perhaps add an optional-packages: section where stack would look for a .cabal file and only include the listed directory if a .cabal file was found?

CC @JPMoresmau

[mgsloan]

Related issue: #1722

For now I would recommend having multiple stack.yaml files. Fancier config would be nice, but we have bigger fish to fry. It's been discussed in the past, and so far we've held off from doing fancy config merging / conditionals / environment interpolation. There are lots of benefits to having simple configuration.

Alternatively, have a dummy cabal file in the package dir - it can be named something else to avoid it looking like it exists.

[mgsloan]

Note that the inclusion here is just with stack build with no explicit targets. From the discussion on reddit, I just realized that you may not have been aware of the distinction between extra-dep and package. It's a bit non-obvious, but packages are things that should are built by default by stack build.

In the package list, you can do the following:

packages:
- location: haskell-gi
  extra-dep: true

See the relevant section of docs

[mgsloan]

Ah, I see now that the issue is that there is no cabal file. Eugh, how about just put a dummy cabal file there?

[dnadales]

I've been following this issue but I'm not sure it is related to the problem we have. Due to licensing issues we need to build with using the integer-simple implementation on windows platforms, which forces us to have two stack files. For instance:

stack.yaml (for windows):

extra-deps:
- text-1.2.2.2

flags: 
  text: 
    integer-simple: true

stack_linux.yaml:

extra-deps:
# Nothing, no problem with integer GMP licensing on Unix systems

This not only doubles the maintenance efforts, but breaks editor tools on Linux (like intero) which expect a working stack.yaml file.

I guess this issue cannot be solved in the way @mgsloan indicated, or can it?

[hamishmack]

Cool. It does looks like this is no longer an issue for Leksah (so we only need one stack.yaml now leksah/leksah@ee8b70f). Thanks.

[dtaskoff]

@capitanbatata, I think your issue is #3369

[dnadales]

@leohaskell It is indeed. But that one was closed, and it refers to this one. Do you also maintain two stack files?

[dtaskoff]

@capitanbatata, it's not closed yet, it's in discussion state.
Yes, I do maintain two stack files at the moment, but I hope that this will change soon.

[mgsloan]

It may be feasible / desireable to have conditionals that are in the same form as hpack, for consistency. Primary concerns:

• Does this mean that stack configurations would get the equivalent of cabal flags? Another layer of toggleable flags?!

• It complicates automated refactoring of stack.yaml. Perhaps the solution is to not worry about it.

In general, it seems complicated to make the configuration more and more like a program, I like to keep it simple while handling 95% of cases. A potential workaround for y'all is to name neither of your stack.yaml files "stack.yaml", and have a simple ./configure.hs stack script which checks the environment and creates a symlink or copy of the appropriate stack.yaml

I have to look at how much complexity / bug surface area / maintainability this would add to stack, atop the complexity of implementi0ng it the first place, versus how many times it's actually useful. Strongly leaning towards "have a ./configure.hs" script at least in the short to medium term.

I haven't looked into dhall much, but it seems cool. Maybe one long term direction would be to switch to it. Then, many of the concerns of having programmatic configuration would not be the responsibility of the stack project.

[dnadales]

I understand this might be tricky to implement, and maybe it could be solved somewhere else. Regarding the ./configure.hs script (or did you mean ./configure.sh ;) ) I don't know if you can make symbolic links on Windows platforms (starting from Windows 7 at least...). Is there a possibility that this conditional inclusion or selection of packages could be solved at the cabal level?

[dtaskoff]

In general, it seems complicated to make the configuration more and more like a program, I like to keep it simple while handling 95% of cases.

I completely understand that from a maintainability perspective.

A potential workaround for y'all is to name neither of your stack.yaml files "stack.yaml", and have a simple ./configure.hs stack script which checks the environment and creates a symlink or copy of the appropriate stack.yaml

This is the same as having multiple .yaml configurations and calling stack build --stack-yaml ... which is exactly the thing I don't want to do. The reason is that it's hard to keep all the configurations in sync, especially when they're dynamically changing (with each LTS, for example). In my case, I have four configurations and that's really a burden.

A better thing to do is to have a configure.hs (it's not sh, @capitanbatata, it's a stack script), which joins a general configuration with a configuration specific for the current environment, but I'd still prefer to keep that in a single file, though if the configure.hs is carefully written, it's not that bad.

[dnadales]

(it's not sh, @capitanbatata, it's a stack script),

Thanks.

Regarding how useful it would be, I guess that every Haskell project that aims at being multi-platform and not licensed under the GPL license will run into this issues, since on Windows you need libraries to use integer-simple.