threadscope on ghc 8.2.2 uses older cabal than cabal that 8.2.2 ships with
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?
How does it depend on cabal? Via some other package?
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... ...
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.
...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 https://github.com/simonmar/alex/pull/120