linj: re: justStaticExecutables. This is interesting. I have been advocating to replace justStaticExecutables with enableSeparateBinOutput because I was not aware of any downsides of the later (when it works. It can cause build errors because of problems with cabal). And I always found it more elegant to reuse the library output instead of just deleting it.

No I am wondering whether that was a bad direction.

linj: re: justStaticExecutables. This is interesting. I have been advocating to replace justStaticExecutables with enableSeparateBinOutput because I was not aware of any downsides of the later (when it works. It can cause build errors because of problems with cabal). And I always found it more elegant to reuse the library output instead of just deleting it.

Now I am wondering whether that was a bad direction.

In reply to @maralorn:maralorn.de
It is also kinda doubtful that the library docs of cachix are actually usefull docs for users of the executable.

In reply to @sellout:matrix.org
I’m having an issue with using a cabal-version other than the one included with GHC. There is a Cabal bug that was fixed in 3.10.3. I updated my Cabal files to include cabal-version: 3.10.3, but my packages support back to GHC 9.6.1 (and the first with Cabal 3.10.3 is GHC 9.8.3). I’ve tried overriding Cabal/Cabal-syntax/cabal-install for GHCs older than 9.8.3, but I still get the complaint “Unsupported cabal-version 3.10.3.” Interestingly, the workaround I managed to find is if I override Cabal to 3.10.3.0, but let cabal-version be set to something older, it works. Maybe this is actually the correct thing – the Cabal file can be parsed with an older Cabal, but Setup requires the non-broken one?

In reply to @sellout:matrix.org
I’m using setup-depends already (because of another Cabal bug), and yeah, that plus the Cabal override is my workaround, which /does/ work. It’s good to hear that that distinguishing the two references to Cabal is useful. But it does leave a few open questions 1. Nix (cabal2nix?) doesn’t pay any attention to setup-depends bounds (if I don’t override Cabal, it complains that it couldn’t load the plugin, not that the bound wasn’t satisfied – which is bad for discovery); 2. my Setup doesn’t actually have a direct dependency on Cabal, so it’s odd that I have to specify it at all, and 3. it still doesn’t help in the case that I would want to have a Cabal file with syntax from a Cabal newer than the one shipped with the corresponding GHC.

Nixpkgs always uses a specific version of every package.
The boot libraries, e.g. Cabal, are whatever version is built into that particular version of GHC.

It's still not entirely clear what you're trying to do.
Build failures because Cabal is too old is, as far as I can tell, working as intended.

Note that cabal-version is the version of the Cabal package description, not the version of Cabal the library, nor the version of cabal-install the executable.
It looks like there is no 3.10.3, so that could be why you get the "unsupported" error even when using a Cabal version that supports 3.12.
You should not change cabal-version unless you need syntax or fields from a newer version.

Is it possible to downgrade my Haskell-Language-Server version for testing purposes? I'm using this shell.nix:

{ pkgs ? import <nixpkgs> {} }:
let
  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
  myPkg = pkgs.haskellPackages.callCabal2nix "aoc25" src {};
in
pkgs.stdenv.mkDerivation {
  name = "aoc-shell";

  buildInputs = [
    myPkg.env.nativeBuildInputs

    pkgs.haskell-language-server
    pkgs.cabal-install
    pkgs.hlint
  ];
}