Error without any exceptions

[boris-stepanov]

General summary/comments

Stack doesn't properly resolve dependencies between libraries and test-suites. I found it while refactoring my own code, so it's a real world scenario. Solution it to add "L1" as a dependency for "E1" test-suite.

Steps to reproduce

1. Create 3 projects: L1, L2, E1.
2. Create stack.yaml:

resolver: lts-11.22
packages:
    - L1
    - L2
    - E1

3. Create L1/L2/E1 cabal files: (minimum configuration is here)

name:                  L1
version:               1.0

library

Test-Suite tests
  type:                exitcode-stdio-1.0
  main-is:             Test.hs
  build-depends:       L2 -any

name:                  L2
version:               1.0

library
  build-depends:       L1 -any

name:                  E1
version:               1.0

Test-Suite tests
  type:                exitcode-stdio-1.0
  main-is:             Test.hs
  build-depends:       L2 -any

4. Run stack test

Expected

Stack throws somewhat like Dependency cycle detected in packages: [L2,L1,L2,E1] or fails on compile stage.

Actual

Stack fails while constructing a plan with empty error message:

$ stack  test
 
Warning: Cabal file warning in /home/haskell/stack/L1/L1.cabal@ 0:0: A package
         using section syntax must specify at least 'cabal-version: >= 1.2'.

Warning: Cabal file warning in /home/haskell/stack/L2/L2.cabal@ 0:0: A package
         using section syntax must specify at least 'cabal-version: >= 1.2'.

Warning: Cabal file warning in /home/haskell/stack/E1/E1.cabal@ 0:0: A package
         using section syntax must specify at least 'cabal-version: >= 1.2'.

Error: While constructing the build plan, the following exceptions were encountered:



Some different approaches to resolving this:

  * Set 'allow-newer: true'
    in /home/haskell/.stack/config.yaml to ignore all version constraints and build anyway.

  * Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some
    working build configuration. This can be convenient when dealing with many complicated
    constraint errors, but results may be unpredictable.


Plan construction failed.

Stack version

$ stack --version
Version 1.9.1, Git revision f9d0042c141660e1d38f797e1d426be4a99b2a3c (6168 commits) x86_64 hpack-0.31.0

Method of installation

Official binary, downloaded from stackage.org.

[dbaynard]

Hi @boris-stepanov, thanks for the report. I'll test this out tomorrow. Meanwhile, would you please re-run with --verbose and paste the output here?

Dependency cycle detected in packages: [L2,L1,L2,E1]

The test suites of L1 and E1 depend on L2, and L2 depends on L1. This isn't actually a cycle, correct?

stack may interpret it as a cycle, in which case the backpack preparation changes will help here (I believe much is already in master).

[boris-stepanov]

Hi @dbaynard, thanks for the response. Here is the gist.
Right, this is not a cycle. We could build them in such progression: L1 -> L2 -> L1 test -> E1 test.

[dbaynard]

OK, I can reproduce

[dbaynard]

I believe the issue is that stack configures packages on a per-package basis, not a per-component basis. (A component is a library, test suite, or executable; a package may have multiple components). I'll try to confirm this.

[dbaynard]

There are a few more variations, too, e.g. does it work with (missing) transitive dependencies where there is no package cycle?

[boris-stepanov]

@dbaynard, uhm, sorry, are you waiting for my response?

There are a few more variations, too, e.g. does it work with (missing) transitive dependencies where there is no package cycle?

I am not sure, can you provide cabal files for example?

[dbaynard]

Ah, sort of… although (via @snoyberg) packages must have at least a library or executable; E1 has just a test suite. I meant to check that but I haven't had a chance.

Let's try that first, then we can look at my more complicated suggestion… and thank you for your patience.

[dbaynard]

Adding a library stanza to E1 does not fix the issue.

I did some stack dot testing and produced the following:

stack dot

stack dot --test

With the library stanza in E1, the former becomes

which indicates the rank=max modifier now applies to E1.

[boris-stepanov]

Adding "L1" as a dependency for "E1" gives such graph:

It's a surprise, but stack resolves this graph successfully.

[dbaynard]

Related: #2583

Actually, this may be a duplicate?