haskellPackages: update stackage and hackage

[cdepillabout]

This Merge

This PR is the regular merge of the haskell-updates branch into master.

This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates. You may be able to find an up-to-date Hydra build report at cdepillabout/nix-haskell-updates-status.

We roughly aim to merge these haskell-updates PRs at least once every two weeks. See the @NixOS/haskell team calendar for who is currently in charge of this branch.

haskellPackages Workflow Summary

Our workflow is currently described in pkgs/development/haskell-modules/HACKING.md.

The short version is this:

• We regularly update the Stackage and Hackage pins on haskell-updates (normally at the beginning of a merge window).
• The community fixes builds of Haskell packages on that branch.
• We aim at at least one merge of haskell-updates into master every two weeks.
• We only do the merge if the mergeable job is succeeding on hydra.
• If a maintained package is still broken at the time of merge, we will only merge if the maintainer has been pinged 7 days in advance. (If you care about a Haskell package, become a maintainer!)

---

This is the follow-up to #220972. Come to #haskell:nixos.org if you have any questions.

[cdepillabout]

@domenkozar I removed some overrides for cachix in c69399d in order to get it to build. It looks like it has been bumped to 1.4 on hackage. Just a heads-up.

[cdepillabout]

@roberth Just a ping that hercules-ci-agent and related packages are failing. Probably due to the update in the cachix version:

https://github.com/cdepillabout/nix-haskell-updates-status/tree/c4cf9c473f04227edae5a213d3ba47171eeb04dc

[roberth]

This makes hls build, but I probably did things the wrong way, like putting a global override on ghcide deps in Nix code?
So fyi this builds: https://github.com/NixOS/nixpkgs/compare/haskell-updates...hercules-ci:nixpkgs:haskell-updates-hls?expand=1

[maralorn]

This makes hls build, but I probably did things the wrong way, like putting a global override on ghcide deps in Nix code? So fyi this builds: https://github.com/NixOS/nixpkgs/compare/haskell-updates...hercules-ci:nixpkgs:haskell-updates-hls?expand=1

Thank you! I actually do think that a global override is the correct solution, but I would do it differently. otoh, I think we can simply to another hackage bump and starting working on hls 1.10.

[cdepillabout]

@roberth @maralorn Thanks for looking into this.

I bumped the hackage snapshot. Let's see what the fallout looks like from this, and if it is too bad we could always revert the commit and just pin ghcide.

[maralorn]

Okay everyone, let’s fix hls 1.10.

I am a big fan of what sterni did with the cabal overrides inherit trick in

nixpkgs/pkgs/development/haskell-modules/configuration-common.nix

Lines 41 to 101 in b1581c3

	inherit (
	let
	# !!! Use cself/csuper inside for the actual overrides
	cabalInstallOverlay = cself: csuper:
	lib.optionalAttrs (lib.versionOlder self.ghc.version "9.6") {
	Cabal = cself.Cabal_3_10_1_0;
	Cabal-syntax = cself.Cabal-syntax_3_10_1_0;
	} // lib.optionalAttrs (lib.versionOlder self.ghc.version "9.4") {
	# We need at least directory >= 1.3.7.0. Using the latest version
	# 1.3.8.* is not an option since it causes very annoying dependencies
	# on newer versions of unix and filepath than GHC 9.2 ships
	directory = cself.directory_1_3_7_1;
	# GHC 9.2.5 starts shipping 1.6.16.0 which is required by
	# cabal-install, but we need to recompile process even if the correct
	# version is available to prevent inconsistent dependencies:
	# process depends on directory.
	process = cself.process_1_6_17_0;
	# hspec < 2.10 depends on ghc (the library) directly which in turn
	# depends on directory, causing a dependency conflict which is practically
	# not solvable short of recompiling GHC. Instead of adding
	# allowInconsistentDependencies for all reverse dependencies of hspec-core,
	# just upgrade to an hspec version without the offending dependency.
	hspec-core = cself.hspec-core_2_10_10;
	hspec-discover = cself.hspec-discover_2_10_10;
	hspec = cself.hspec_2_10_10;
	# hspec-discover and hspec-core depend on hspec-meta for testing which
	# we need to avoid since it depends on ghc as well. Since hspec*_2_10*
	# are overridden to take the versioned attributes as inputs, we need
	# to make sure to override the versioned attribute with this fix.
	hspec-discover_2_10_10 = dontCheck csuper.hspec-discover_2_10_10;
	# Prevent dependency on doctest which causes an inconsistent dependency
	# due to depending on ghc which depends on directory etc.
	vector = dontCheck csuper.vector;
	};
	in
	{
	cabal-install = super.cabal-install.overrideScope cabalInstallOverlay;
	cabal-install-solver = super.cabal-install-solver.overrideScope cabalInstallOverlay;
	guardian = lib.pipe
	# Needs cabal-install >= 3.8 /as well as/ matching Cabal
	(super.guardian.overrideScope (self: super:
	cabalInstallOverlay self super // {
	# Needs at least path-io 1.8.0 due to canonicalizePath changes
	path-io = self.path-io_1_8_0;
	}
	))
	[
	# Tests need internet access (run stack)
	dontCheck
	# May as well…
	(self.generateOptparseApplicativeCompletions [ "guardian" ])
	];
	}
	) cabal-install
	cabal-install-solver
	guardian
	;

, so if we need complicated overrides I would like to transition hls to use that trick. I guess I will go ahead and refactor the override in the -nix.nix that way. Also I would like to duplicate less work between ghc versions and work more with versionAtLeast in the common.nix

Besides that I suggest we coordinate a bit with fixing the builds:

• 8.10
• 9.0
• 9.2 (default)
• 9.4
• 9.6

Maybe if you work on a version drop a line in #haskell:nixos.org so everyone knows and we can potentially split efforts.

/cc @ncfavier because you were so helpful last time

[vcunat]

I think we'll need haskell-gi/haskell-gi#401 for/before #224806
(Hydra error)

[sternenseemann]

@vcunat #225231 has the version of haskell-gi including the fix, not sure if it'll propagate to master in time, but any broken period should be short, so maybe okay.

[vcunat]

I was just puzzled that it started to work and I don't know why: https://hydra.nixos.org/job/nixpkgs/staging-next/haskellPackages.gi-glib.x86_64-linux
(maybe something in this haskell-updates already)

[sternenseemann]

@vcunat Was part of this PR apparently, so it must have propagated from master to staging-next now.

[vcunat]

Ah, so .haskell-gi version was relevant and not .gi-glib version? https://hydra.nixos.org/job/nixpkgs/staging-next/haskellPackages.haskell-gi.x86_64-linux

[vcunat]

The upstream repo and versioning around haskell-gi is confusing me all the time.

[sternenseemann]

Yes, the changed module belongs to haskell-gi.