threadscope on ghc 8.2.2 uses older cabal than cabal that 8.2.2 ships with

[GeorgeCo]

minor but I thought it may be worth mentioning: 8.2.2 and I believe 8.2.1 ship with cabal 2.0
But threadscope uses cabal 1.24.2
Would it be possible to fix so 8.2.2 with threadscope uses one version of cabal rather than two?

[Mikolaj]

How does it depend on cabal? Via some other package?

[GeorgeCo]

Sorry, not sure. As you point out it may not be a threadscope issue. What I see is:

cabal install -j5 threadscope
Resolving dependencies...
Configuring ghc-events-0.6.0...
Configuring file-embed-0.0.10.1...
Configuring hashtables-1.2.2.1...
Configuring temporary-1.2.1.1...
Configuring process-1.4.3.0...
Building file-embed-0.0.10.1...
Building ghc-events-0.6.0...
Building hashtables-1.2.2.1...
Building temporary-1.2.1.1...
Building process-1.4.3.0...
Configuring utf8-string-1.0.1.1...
Installed file-embed-0.0.10.1
Installed temporary-1.2.1.1
Building utf8-string-1.0.1.1...
Installed process-1.4.3.0
Configuring Cabal-1.24.2.0...
Building Cabal-1.24.2.0...
Installed utf8-string-1.0.1.1
Installed hashtables-1.2.2.1
Installed ghc-events-0.6.0
Installed Cabal-1.24.2.0
Configuring gtk2hs-buildtools-0.13.3.0...
...

[Mikolaj]

IIRC, the gtk packages depend on cabal. I so, we may verify that our dependency on gtk includes the newest versions. If it does, we can only wait for gtk maintainers to update their dependency on cabal. However, I guess, technically TS depends only on one version of cabal and it's GHC that depends on another. So I think there is nothing to worry about.

[hvr]

...you can use cabal-plan to investigate the install-plans. And fwiw, cabal new-build -w ghc-8.2.2 --constraint 'setup.Cabal installed' was able to find an install-plan which used only Cabal-2.0.1.0 ...

PS: ...and it seems this is caused by the qualified alex sub-goals (because constraining to Cabal installed pushes the cabal solver to pick a non-recent alex release) ; this recurring issue could be resolved for good by haskell/alex#120