Without the change the eval fails as:
$ nix build --no-link -f. haskell.packages.ghc865Binary.exceptions
error: attribute 'exceptions_0_10_7' missing
at pkgs/development/haskell-modules/configuration-ghc-8.6.x.nix:98:16:
97| # This became a core library in ghc 8.10., so we don’t have an "exception" attribute anymore.
98| exceptions = self.exceptions_0_10_7;
| ^
99|
Did you mean exceptions_0_10_8?
In https://github.com/NixOS/nixpkgs/pull/278074 I removed `exception`
completely. But `nixpkgs` has a version of `exceptions we could use.
Let's enable that instead.
Co-authored-by: Dennis Gosnell <cdep.illabout@gmail.com>
`haskell.packages.ghc865Binary` has a few packages that fails to evaluate
by referring non-existent attributes. This turns evaluation attempts into
unrecoverable errors.
Before the change an attempt to instantiate all `ghc810` packages failed
as:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; lib.mapAttrs (n: v: builtins.tryEval (lib.isDerivation v)) haskell.packages.ghc865Binary'
error:
… while evaluating the attribute 'llvmPackages'
at lib/attrsets.nix:1180:11:
1179| attrs:
1180| attrs // { recurseForDerivations = false; };
| ^
1181|
error: value is null while a set was expected
The change follows definition of `pkgs/top-level/haskell-packages.nix`
and also sets `llvmPackages` to `null`. While at it dropped other
references to deleted packages like `exceptions` pin.
The main motivation for this is that the latest versions of hspec-core
and hspec-expectations got out of sync due to an unlucky timing on the
hackage snapshot update. As a consequence, we weren't able to build
cabal-install in some package sets. Additionally, this brings a version
of futhark that can be built with the lsp version we ship.
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
and maintainers/scripts/haskell/regenerate-hackage-packages.nix.
Additional changes:
* Adapt to new xhtml version (still doesn't match the version normally
shipped by the respective GHC as a core library).
* Adapt to new versions of hspec* and pandoc
Some packages cabal-install needed a certain version range (cabal-install-solver
and resolv) have versions incompatible with these in Stackage LTS 21. We can,
however, easily provide the necessary ones.
Additionally, we clean up some old resolv related overrides that are no longer
necessary or we no longer care about (being able to build cabal-install with
GHC 8.6, namely).
Before Cabal >= 3.8, Cabal-syntax did not exist, but there is a dummy
package Cabal-syntax-3.6.0.0 which can be used to prevent the constraint
solver from picking mutually incompatible versions of Cabal and
Cabal-syntax. Since we are now solving flags with Cabal >= 3.8, many
packages have a dependency on Cabal-syntax they did not have before,
requiring us to have a matching attribute in every package set. Using
the dummy package is the safest solution, although it is not required in
every case.
Fixes eval of jailbreak-cabal for GHC < 9.4.
terminfo had a new release on hackage and we only ship the latest
version currently, so every GHC gets the newest version. Whether this is
correct, is another question, occurs to me – we'll have to look into
whether we should fix this at some point.
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
This is a dependency of cabal-install and builds by virtue of its
overrideScope. We also want to make sure it builds independently, so
that it doesn't get marked as broken at the very least.
GHC's cross build flavours disable the terminfo package, so it will
never be included if we are cross-compiling – setting it to null thus
breaks all builds depending on the package.
To fix this problem, we use the versioned attribute generated by
hackage2nix, just like we do for xhtml.
Closes#182785.
The xhtml library is only built as part of the GHC build process if GHC
is disabled. This means that no GHC cross compiler has xhtml bundled,
since haddock can't be built if GHC is a cross compiler (see relevant
notes in the GHC nix expressions). This means that all packages
depending on xhtml would currently fail to build when cross-compiled, as
haskellPackages would assume it'd be provided by GHC. This is fixed by
this commit.
pkgsStatic hits this case, so we test compilation of xhtml for these
package sets which will remind us to update the attribute name whenever
its version changes.
This means we only have to update the llvmPackages attribute in one
place now and should prevent situations like with 8.6.5 where different
versions would be used in the package set compared to the compiler
build.
Drop comments in the configuration-ghc-X.Y.x.nix files as well, since
LLVM version isn't tied to the compiler minor version at
all (e. g. 8.10.2 and 8.10.7 have different support ranges).
* 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.
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
`cabal2nix` fails to evaluate due to attempting to
evaluate `pkgs.haskellPackages.hackage-db_2_1_0`, which
does not exist. However, the default
`pkgs.haskellPackages.hackage-db` is already version 2.1.0,
so the fix is simple: go back to using the default version.
Without this change, the build fails with:
```
Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package hackage-db (hackage-db-2.0.1-AliTRXEJBGFAEMpONOEnbV) requires Cabal-2.4.0.1
package hpack (hpack-0.32.0-1iJuukTWmC4EGkYhAiFeII) requires Cabal-3.0.0.0-CD1INMNwoxXIKVgcu1nec5
package distribution-nixpkgs (distribution-nixpkgs-1.3.1-82Z2DCdLAUs8Q2gjtlPLz5) requires Cabal-3.0.0.0-CD1INMNwoxXIKVgcu1nec5
package cabal2nix (cabal2nix-2.15.0) requires Cabal-3.0.0.0-CD1INMNwoxXIKVgcu1nec5
package cabal2nix (cabal2nix-2.15.0) requires Cabal-3.0.0.0-CD1INMNwoxXIKVgcu1nec5
package cabal2nix (cabal2nix-2.15.0) requires Cabal-3.0.0.0-CD1INMNwoxXIKVgcu1nec5
```
