| 28 Jan 2026 |
 Daniel Firth | Hey guys. We're looking at trying to include the cardano-node in nixpkgs. I'm thinking of ways to do this and obviously since it involves CHaP and also significantly deviates from stackage just on the hackage dependencies I'm wondering if you have any thoughts on what you would accept as a way to this. | 11:35:25 |
| Daniel Firth | * Hey guys. We're looking at trying to include the cardano-node in nixpkgs. I'm thinking of ways to do this and obviously since it involves CHaP and also significantly deviates from stackage just on the hackage dependencies I'm wondering if you have any thoughts on what you would accept as a way to do this. | 11:35:37 |
 maralorn | What’s CHaP? | 11:39:30 |
| maralorn | I am pretty sure there are examples on how to package non-hackage packages in nixpkgs. | 11:40:13 |
| maralorn | Including some with a non-neglectable number of overrides. | 11:40:47 |
| maralorn | Actually I think even cachix does it. | 11:41:01 |
|  Robin Stumm joined the room. | 11:48:38 |
| Robin Stumm | https://github.com/IntersectMBO/cardano-haskell-packages | 11:49:23 |
| Daniel Firth | We could be looking at more than 50% of the build plan would be custom, so 300 or more packages. | 11:52:13 |
| maralorn | Oooh. | 11:54:09 |
| maralorn | I mean I wonder how large that would be in comparison to other large derivation packages in nixpkgs. Like those with a checked in npm or cargo lock. | 11:55:36 |
| Daniel Firth | It would be more or less exactly the same size as the equivalent horizon expression here. https://gitlab.horizon-haskell.net/package-sets/horizon-cardano
nix build 'git+https://gitlab.horizon-haskell.net/package-sets/horizon-cardano#horizon-cardano'
| 11:57:33 |
| maralorn | If you can encapsulate it cleanly (i.e. without interfering with the rest of haskellPackages) and the size is manageable it seems fine-ish. Of course there is then also the matter of maintainership. It mustn’t become a burden on the haskell team. | 11:57:39 |
| Daniel Firth | That would be one option to just upstream the whole horizon expression under haskellPackages.horizon.cardano, if that's something nixpkgs would accept. | 11:58:10 |
| Daniel Firth | Would be much easier than trying to solve which parts of nixpkgs could be reused. | 11:58:36 |
| Daniel Firth | * It would be more or less exactly the same size as the equivalent horizon expression here. https://gitlab.horizon-haskell.net/package-sets/horizon-cardano
nix build 'git+https://gitlab.horizon-haskell.net/package-sets/horizon-cardano#cardano-node'
| 11:58:56 |
| maralorn | I am sceptical. Also curious what the others think. | 12:01:00 |
| maralorn | Maybe we can have this discussion more organized on a GitHub issue? | 12:01:32 |
| Daniel Firth | It would basically be a wholly independent package set. It might reuse the ghc definition but nothing else. | 12:01:42 |
| Daniel Firth | Sure. I'll write it up. | 12:01:46 |
 toonn | What is the goal? Are there existing dependents that would be desirable to package for users? | 12:03:40 |
| toonn | End-users, not developer-users. | 12:03:54 |
| Daniel Firth | The goal is to package cardano-node for end users yes, not developers. But maintaining the build plan for cardano-node manually in nixpkgswith overrides and whatnot would be infeasible. | 12:05:21 |
| Daniel Firth | Occasionally dropping a new horizon expression as a separate package set expression into nixpkgs, one that didn't interfere with haskellPackages proper, would be quite easy for me to automate, it just depends whether that's OK or not. | 12:08:34 |
| 29 Jan 2026 |
 alexfmpe | when using pkgsStatic on my aarch64-darwin, most packages correctly build only the .o
$ nix-build -A pkgsStatic.haskell.packages.ghc910.these
Building library for these-1.2.1...
[1 of 3] Compiling Data.Functor.These ( src/Data/Functor/These.hs, dist/build/Data/Functor/These.o )
however there's a few odd ones where .dyn_o is also attempted
$ nix-build -A pkgsStatic.haskell.packages.ghc910.deferred-folds
Building library for deferred-folds-0.9.18.7...
[ 1 of 11] Compiling DeferredFolds.Prelude ( library/DeferredFolds/Prelude.hs, dist/build/DeferredFolds/Prelude.o, dist/build/DeferredFolds/Prelude.dyn_o )
$ nix-build -A pkgsStatic.haskell.packages.ghc910.constraints-extras
Building library for constraints-extras-0.4.0.2..
[1 of 4] Compiling Data.Constraint.Compose ( src/Data/Constraint/Compose.hs, dist/build/Data/Constraint/Compose.o, dist/build/Data/Constraint/Compose.dyn_o )
$ nix-build -A pkgsStatic.haskell.packages.ghc910.language-nix
Building library for language-nix-2.3.0...
[1 of 4] Compiling Language.Nix.Identifier ( src/Language/Nix/Identifier.hs, dist/build/Language/Nix/Identifier.o, dist/build/Language/Nix/Identifier.dyn_o )
unsurprisingly, these all fail with Failed to load dynamic interface file for <import>
| 01:25:46 |
| alexfmpe | but where are these random .dyn_o coming from? | 01:26:03 |
| alexfmpe | we're passing both
--disable-shared
--disable-executable-dynamic
| 01:27:58 |
| alexfmpe | these / language-nix got pretty much the same configureFlags, save for the package-db | 01:39:34 |
| alexfmpe | diff these.flags language-nix.flags
3c3
< --prefix=/nix/store/2p9mikrs1a5awxgw5gijxf3pqdfwbx72-these-static-arm64-apple-darwin-1.2.1
---
> --prefix=/nix/store/x7msfranpbk5bpjk9mk22jh56m2yz235-language-nix-static-arm64-apple-darwin-2.3.0
7c7
< --package-db=/nix/var/nix/builds/nix-3587-2546165707/tmp.EqliYPG7Mk/package.conf.d
---
> --package-db=/nix/var/nix/builds/nix-95530-279909260/tmp.E7z4UnZFfa/package.conf.d
| 01:39:37 |
| alexfmpe | curiously I can trigger the same by enabling haddocks for pkgsStatic, but for a different set of packages | 02:02:00 |
