How to build the testsuite?

[andreasabel]

What is the magic trick to build (and run) the testsuite?
Build fails because of the dependency cycle pretty:test -> containers -> template-haskell -> ghc-boot-th -> pretty.

$ cabal build --enable-tests                                                                                                         
Could not resolve dependencies:
[__0] trying: pretty-1.1.3.6 (user goal)
[__1] trying: pretty:*test
[__2] trying: QuickCheck-2.16.0.0 (dependency of pretty *test)
[__3] trying: splitmix-0.1.3.1 (dependency of QuickCheck)
[__4] trying: containers-0.7/installed-f896 (dependency of QuickCheck)
[__5] trying: template-haskell-2.23.0.0/installed-9d0c (dependency of containers)
[__6] next goal: ghc-boot-th (dependency of template-haskell)
[__6] rejecting: ghc-boot-th-9.12.2/installed-9353 (package is broken, missing dependency pretty-1.1.3.6-1375)
[__6] rejecting: ghc-boot-th; 9.10.2, 9.10.1, 9.8.1, 9.6.6, 9.6.3, 9.6.1, 9.4.1, 9.2.2, 9.2.1, 9.0.1, 8.10.2, 8.10.1, 8.8.3, 8.8.1, 8.6.5, 8.6.4, 8.6.1, 8.4.4, 8.4.3, 8.4.2, 8.4.1, 8.2.2, 8.2.1, 8.0.2, 8.0.1 (conflict: template-haskell => ghc-boot-th==9.12.2/installed-9353)
[__6] fail (backjumping, conflict set: ghc-boot-th, template-haskell)

The cycle could maybe be broken if containers made template-haskell optional:

• Cabal flag to build without template-haskell containers#1156

[treeowl]

I'm a bit confused. If only the tests rely on containers, why is there a loop?

[andreasabel]

It is still that when you want to build the tests for pretty, it wants containers -> template-haskell -> ghc-boot-th -> pretty and so there is a conflict between the pretty one is building and the pretty that is a dependency of ghc-boot-th (which is not an rebuildable package).

I can build the tests if I rename package pretty to something else, so that the conflict goes away.

[meooow25]

It is still that when you want to build the tests for pretty, it wants containers -> template-haskell -> ghc-boot-th -> pretty and so there is a conflict between the pretty one is building and the pretty that is a dependency of ghc-boot-th (which is not an rebuildable package).

This looks like an issue with ghc-boot-th. According to Hackage (https://hackage.haskell.org/package/ghc-boot-th), ghc-boot-th depends only on base.

I've also found that tests are building fine with GHC 9.6.7 and this error occurs only with >= GHC 9.8.

[andreasabel]

@meooow25 wrote:

I've also found that tests are building fine with GHC 9.6.7 and this error occurs only with >= GHC 9.8.

Good observation.
template-haskell depends on pretty (since long), but this dependency was shipped out to ghc-boot-th in 9.12. And since Hackage's ghc-booth-th is still on 9.10.2, you cannot see it there.

With 9.6. containers-0.6.5.1 was shipped which did not depend on template-haskell.
With 9.8, containers-0.6.8 was shipped which introduced the dependency on template-haskell (since 0.6.6 actually). This broke the testsuite of pretty.

[meooow25]

Thanks for the explanation, the breakage makes sense now.

I'm curious why Cabal tries to build pretty up-front, since test-pretty does not depend on it. It instead includes the source directory in the test target. A workaround might be to put the test suite in a separate package like containers does.

I don't think removing template-haskell from containers will be sufficient since there's also QuickCheck -> random -> bytestring -> template-haskell.

[TeofilC]

I mentioned this on the GHC ticket, but I'm currently working on creating a new template-haskell-lift package, which coincidentally should also fix this. containers, bytestring, etc only depend on template-haskell in order to define Lift instances. And the new package will only have a dependency on ghc-internal. So we won't have this issue.

[andreasabel]

@meooow25 wrote:

A workaround might be to put the test suite in a separate package

Thanks for the idea. This would require the creation of .Internal modules though and quite a bit of restructuring. (Or some sharing of the pretty implementation between the two packages.)

I think I wait for the outcomes of @TeofilC 's project before considering this.
(There is still a cheaper option to temporarily rename pretty to pretty-sut or something to run tests and benchmarks, ugly hack though...)