Automatically use sed(1) to remove DOS line endings from .cabal files.
This is intended to work around Hackage producing revised cabal files
with DOS line endings (https://github.com/haskell/hackage-server/issues/316).
This frequently leads to
- patches failing to apply. Unfortunately there is no way to apply a
patch with Unix line endings to a file with DOS line endings with
GNU patch(1). Only the following combinations are supported:
file patch comment
Unix Unix
DOS DOS using --binary
DOS Unix Haven't tested it, but I assume it works because
patch(1) converts the file to Unix line endings
implicitly (which can be disabled using --binary),
but never the patch…
- Test suites sometimes involve the .cabal file which can be
affected by the line endings.
This behavior is enabled by default to prevent cases where (unrevised)
packages regress when they get a revision later. Of course, the behavior
is a little nonsensical for non-Hackage packages, but it is probably
rarely an issue in practice. When DOS line endings need to be preserved,
the user can pass `dontConvertCabalFileToUnix = true`.
Supersedes #279248.
Resolves#206840.
GHC 9.10.2 seems to be unaffected by the i686 issue, so we can use 9.10
almost everywhere, c.f. https://gitlab.haskell.org/ghc/ghc/-/issues/25904.
haskellPackages: stackage LTS 23.27 -> LTS 24.2
all-cabal-hashes: 2025-07-07T21:33:55Z -> 2025-07-28T06:22:26Z
Make sure to retain Cabal and Cabal-syntax == 3.14.* which is currently
used by cabal2nix-unstable.
Previously, setting environment variables in a Haskell package build
required using `.overrideAttrs`, which (I think?) breaks later
invocations of `haskell.lib.overrideCabal`.
This patch adds an `env` argument to `haskellPackages.mkDerivation`,
which can be used to set environment variables during Haskell package
builds.
testTarget takes a space separated list of test suites to run. We itnroduce a new testTargets argument that instead takes a list, and add a backwards compatibility shim
This matches the update from Stackage LTS 22 -> 23 in 7ea7574c.
Regenerate the package set with compiler: ghc-9.8.3 passed to Cabal
using
env \
HACKAGE2NIX=/nix/store/57ivr7wj0bzgkgvgp6i1dsz5rbihy2an-cabal2nix-unstable-2024-12-31/bin/hackage2nix \
bash ./maintainers/scripts/haskell/regenerate-hackage-packages.sh --fast
since cabal2nix-unstable doesn't build yet (I assume).
Both are affected by <https://gitlab.haskell.org/ghc/ghc/-/issues/23762>
which is now cropping up on our CI (for Cabal 3.14). I don't really see
why we absolutely have to keep them, so it seems just better overall to
use this as an excuse to remove them (after NixOS 24.11 branch off).
Allow setting `sourceRoot` and `setSourceRoot` in the arguments to
`haskellPackages.mkDerivation`. These arguments are passed directly to
`stdenv.mkDerivation`.
It may be worth reading over `pkgs/stdenv/generic/setup.sh` and checking
if there's other unsupported variables which may be useful. It may also
be worth adding an argument like `extraAttrs` to be passed to
`stdenv.mkDerivation` directly, as an escape hatch.
this removes the hard-coded listing from the Haskell examples, which can later be replaced by
a dynamic one as for the Python interpreters
* fix broken reference
* clarify why using `nix-env --query` makes sense
Co-authored-by: wamirez <wamirez@protonmail.com>
This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
Fixes#256769
Repro + test of fix here: https://gitlab.com/ramirez7/bug-repros/-/merge_requests/1
Adds a `srcModifier` argument to `callCabal2nixWithOptions` to allow
customizing the source files used to generate the cabal file (e.g. to
support `hpack`/`package.yaml`).
`lib.recursiveUpdate` indiscriminately recurses into all attribute sets,
also into derivations. This means that it is possible that evaluating a
derivation in the final haskell package set can cause something in
`prev.haskell` to be forced by `recursiveUpdate`, potentially causing an
evaluation error that should not happen.
It can be fixed using a well-crafted predicate for
`lib.recursiveUpdateUntil`, but most robust is just explicitly writing
out the desired merging manually.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
This is actually relatively complicated to achieve, since it involves
overriding GHC on e.g. aarch64-darwin, so the FAQ entry seems warranted.
It's also a good exercise to me, since it demonstrates some problems
with the overriding infrastructure, i.e. that it has a tendency to
inherit the pkgs fixpoint from prev. An example of this problem is
https://github.com/NixOS/nixpkgs/issues/235960, but it has different
manifestations as well. Awareness of this will also help writing the
other sections on overriding.
How complicated it is, seems to be further incentive to go ahead with
https://github.com/NixOS/nixpkgs/pull/239548 as well.
without stable ids on headings we cannot generate stable links to these
headings. nrd complains about this, but the current docbook workflow
does not.
a few generated ids remain, mostly in examples and footnotes. most of
the examples are generated by nixdoc (which has since gained MD export
functions, and the MD export does generate IDs).
