Building packages with breakable dependency cycle fails

[kolmodin]

I've had this problem with binary and found a few workarounds. I'm curious if there are any better solutions I'm not aware of. Also, is there something cabal can do to make the workflow easier?

binary depends on packages for its tests and benchmarks. Those packages in turn depend on binary.
I believe this cases an issue when trying to build binary with its tests and benchmarks.

Note that it's binary's tests and benchmarks that introduce the dependencies, not the actual binary library. So with fine grained dependency tracking, there is actually no cycle.

$ cabal new-build --enable-tests --enable-benchmarks 
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: binary-0.8.6.0 (user goal)
[__1] rejecting: binary:!bench (constraint from config file, command line
flag, or user target requires opposite flag selection)
[__1] trying: binary:*bench
[__2] trying: unordered-containers-0.2.9.0 (dependency of binary *bench)
[__3] trying: hashable-1.2.7.0 (dependency of unordered-containers)
[__4] next goal: text (dependency of hashable)
[__4] rejecting: text-1.2.3.1/installed-1.2... (package is broken)
[__4] rejecting: text-1.2.3.1, text-1.2.3.0, text-1.2.2.2, text-1.2.2.1,
text-1.2.2.0, text-1.2.1.3, text-1.2.1.2, text-1.2.1.1, text-1.2.1.0 (cyclic
dependencies; conflict set: binary, hashable, text, unordered-containers)
[__4] trying: text-1.2.0.6
[__5] trying: generic-deriving-1.12.2 (dependency of binary *bench)
[__6] next goal: template-haskell (dependency of generic-deriving)
[__6] rejecting: template-haskell-2.14.0.0/installed-2.1... (conflict: text =>
base>=4.2 && <4.9, template-haskell => base==4.12.0.0/installed-4.1...)
[__6] rejecting: template-haskell-2.14.0.0, template-haskell-2.13.0.0,
template-haskell-2.12.0.0, template-haskell-2.11.1.0,
template-haskell-2.11.0.0, template-haskell-2.10.0.0,
template-haskell-2.9.0.0, template-haskell-2.8.0.0, template-haskell-2.7.0.0,
template-haskell-2.6.0.0, template-haskell-2.5.0.0, template-haskell-2.4.0.1,
template-haskell-2.4.0.0, template-haskell-2.3.0.1, template-haskell-2.3.0.0,
template-haskell-2.2.0.0 (constraint from non-upgradeable package requires
installed instance)
[__6] fail (backjumping, conflict set: generic-deriving, template-haskell,
text)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: template-haskell, generic-deriving,
pretty, base, binary, text, hashable, binary:bench, unordered-containers

I'm aware of two workarounds.

• Using cabal sandbox, manually install dependencies. See example in binary/.travis.yml.
• Using cabal new-build, rename binary to break the cycle. See example in binary/docker/Dockerfile.anyghc.

In both these cases, the dependencies are not built against the binary with tests and benchmarks that I'm trying to compile.

Is the error indeed due to circular dependencies? The dependency solver spits out an error message, it's not clear to me what exactly is wrong.

Cabal has two options;

• Build all dependencies against the new binary and then build the tests and benchmarks against those newly built deps. This will rebuild all dependencies for every change in binary. Probably not too nice workflow as it takes time to iterate.
• Build all dependencies against a binary from hackage. Build the new binary, tests and benchmarks against those dependencies. This means that there will be two versions of binary in the dependency graph which is also not desirable.

Neither of the options are attractive.

I'm sure this issue has arisen for many other packages as well.
It's unfortunate that contributors cannot download the repo, make changes and run the tests without also having to do one of the workarounds.

[quasicomputational]

See #1575. If cabal-install had per-dependency solving (#4987), there's not actually a cycle in that graph. That's your first option, which would work, but it's not quite ideal, as you note.

[grayjay]

Duplicate of #1575