* no released version of hackage2nix does support distribution-nixpkgs yet.
* hackage-db 2.1.2 fixes an annoying bug introduced in 2.1.1 and also supports
Cabal 3.4: https://github.com/NixOS/cabal2nix/issues/501
Stackage Nighly recently upgraded their version of hackage-db from 2.1.0
to 2.1.1. 2.1.1 had a compatibility fix for Cabal 3.4 [1]. However it
did not increase the version bound on Cabal nor fails to compile with
Cabal 3.2, so Stackage was able to update it.
Unfortunately hackage-db with Cabal 3.2 causes observable issues [2]
in cabal2nix, so we need to downgrade it for all compilers that still
ship a Cabal version < 3.4.
Also ideally we should update the constraints for hackage-db 2.1.0 and
hackage-db 2.1.1 on hackage. See also [3].
[1]: https://github.com/peti/hackage-db/pull/12
[2]: https://github.com/NixOS/cabal2nix/issues/501
[3]: https://github.com/peti/hackage-db/pull/14
They are not an exposed part of haskellPackages per se, so we shouldn't
list them in nix-env. Additionally this should prevent the failed lldb
build from cluttering our jobset output.
Commit 1998b95adc “haskellPackages:
update default compiler from ghc 8.10.2 to version 8.10.3” broke Agda
because Agda.cabal incorrectly declares a transformers dependency only
for ghc < 8.10.3:
if impl(ghc >= 8.6.4) && impl(ghc < 8.10.3)
build-depends: transformers == 0.5.6.2
if impl(ghc >= 8.4) && impl(ghc < 8.6.4)
build-depends: transformers == 0.5.5.0
if impl(ghc < 8.4)
build-depends: transformers == 0.5.2.0
leading to this error:
src/full/Agda/Utils/Maybe.hs:13:1: error:
Could not load module ‘Control.Monad.Trans.Maybe’
It is a member of the hidden package ‘transformers-0.5.6.2’.
Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
13 | import Control.Monad.Trans.Maybe
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Tests did not compile.
Message:
test/Servant/SwaggerSpec.hs:44:14: error:
• No instance for (HasSwagger
(Fragment Int :> Servant.Test.ComprehensiveAPI.GET))
arising from a use of ‘toSwagger’
• In the expression: toSwagger comprehensiveAPI
In an equation for ‘_x’: _x = toSwagger comprehensiveAPI
In the second argument of ‘($)’, namely
‘do let _x = toSwagger comprehensiveAPI
True `shouldBe` True’
|
44 | let _x = toSwagger comprehensiveAPI
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
In preparation of the upcoming 0.6.0 release I wanted to fix hls.
It introduces two new plugin packages, which are not on hackage yet.
I remove apply-refact overrides, because current apply-refact versions
are compatible with all ghcs we support, according to their changelog.
I override more of the hls dependencies globally on the whole package
set, to avoid a lot of duplicate compilations. And because @peti changed
my mind about this being a good practice.
hls now uses a released version of ghcide
Stackage wants us to stay at 2.9.x, but that version is really quite old now
and updating the new version actually simplifies our code because a couple of
overrides are no longer necessary.
hnix 0.9.0 does not provide an executable for ghc <8.10 anymore.
So we need to disable optparse-applicative completion generation for all other versions.
