stack sdist fails when modules are exposed based on a flag in the cabal file

[harendra-kumar]

General summary/comments (optional)

The stack sdist command reports duplicate modules when the same module is used in an if-else clause in the cabal file.

Steps to reproduce

The cabal file includes this stanza:

library
    hs-source-dirs:    src
    if flag(dev)
        exposed-modules:
                       Streamly.SVar
                     , Streamly.Streams.StreamK
                     ...
    else
        other-modules:
                       Streamly.SVar
                     , Streamly.Streams.StreamK
                     ...

Expected

stack sdist command should succeed as usual.

Actual

stack --no-terminal --resolver lts-11 --system-ghc sdist
Selected resolver: lts-11.14
Getting file list for /home/travis/build/composewell/streamly/
Building sdist tarball for /home/travis/build/composewell/streamly/
Checking package 'streamly' for common mistakes
Package check reported the following warnings:
'ghc-options: -O0' is not needed. Use the --disable-optimization configure flag.
'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users.
Package check reported the following errors:
Duplicate modules in library: Streamly.SVar, Streamly.Streams.Ahead, Streamly.Streams.Async, Streamly.Streams.Parallel, Streamly.Streams.Prelude, Streamly.Streams.SVar, Streamly.Streams.Serial, Streamly.Streams.StreamD, Streamly.Streams.StreamK, Streamly.Streams.Zip
Error: Command [stack --no-terminal --resolver lts-11 --system-ghc sdist] failed. Exiting.

See this run: https://travis-ci.org/composewell/streamly/jobs/395854970 for the full error output.

Stack version

$ stack --version
Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2

Method of installation

• Official binary, downloaded from stackage.org or fpcomplete's package repository

[isovector]

Thanks for the report! I've managed to reproduce this on v1.6.3. Looking into it now!

[isovector]

This doesn't appear to be an issue with stack; cabal sdist also fails in this scenario. I'm closing this bug as it's an upstream issue. As stack merely calls out to Cabal for these checks, any upstream changes should automatically work in stack too.

[harendra-kumar]

@isovector I had actually checked this before filing the bug, all my cabal builds are succeeding for the same cabal file, and all stack builds are failing. Is it possible that a particular version of cabal has this problem and that is being used by stack?

[harendra-kumar]

See this build job set: https://travis-ci.org/composewell/streamly/builds/395854967 . stack builds have failed due to this problem while cabal builds have succeeded. The only cabal build that failed is due to a network/curl issue.

[isovector]

@harendra-kumar interesting, thanks for reopening. It looks like your build is using Cabal-2.2.0.1 but stack is on Cabal-2.0.1.1. I'll look more closely into this tomorrow; hopefully it's as easy as updating the version bounds.

[harendra-kumar]

Ah, it seems that cabal gives this warning but still creates the tarball and therefore the build succeeds. However, stack does not proceed at all. Maybe we can use the same behavior as cabal?

[harendra-kumar]

I am not sure which one is the correct behavior so please take a call and I will be ok either way.

[isovector]

After some discussion, it seems like the cabal behavior here is misleading in that it was causing CI to pass. Furthermore, despite returning an error code, stack sdist does in fact produce the tarball. I've opened #4117 to mention this. stack seems to have the better behavior here.

If you want the permissive error code of cabal, the --ignore-check flag can be used with stack dist to ignore the checks altogether.

Feel free to reopen if none of these options are satisfactory! Thanks!