| 30 Oct 2025 |
 magic_rb | nix-fast-build nixpkgs#legacyPackages.x86_64-linux.haskellPackages | 22:40:33 |
| magic_rb | I think | 22:40:37 |
 alexfmpe | that fails eval from hitting all the broken packages no? | 23:06:40 |
| magic_rb | It should keep going | 23:06:53 |
| magic_rb | Or there may be a flag | 23:06:57 |
| magic_rb | It internally calls nix-eval-jobs which can definitely just keep going. We use it inside of buildbot-nix | 23:07:36 |
| alexfmpe | wait do you really want ALL of it? that's thousands of packages, all taking up disk space | 23:08:37 |
| alexfmpe | another option is building whatever deps your planned project has, plus a few dependency heavy hitters | 23:09:35 |
| alexfmpe | HLS alone has like 250 | 23:09:39 |
| alexfmpe | $ grep "callPackage" hackage-packages.nix | wc -l
18654
$ grep "broken = true" hackage-packages.nix | wc -l
7267
a few others won't eval because of platform but that still looks like around 10k that will at least attempt to build
| 23:12:01 |
| 31 Oct 2025 |
 Alex | In reply to @alexfmpe:matrix.org
another option is building whatever deps your planned project has, plus a few dependency heavy hitters It's much lighter if you only fetch all transitively required sources.
Though naturally, that means you need to build whatever you want to use. | 01:56:46 |
| 2 Nov 2025 |
|  ➡️@amadaluzia:unredacted.org changed their display name from amadaluzia to ➡️@amadaluzia:unredacted.org. | 22:49:04 |
| 3 Nov 2025 |
 sterni | incredible https://github.com/Tritlo/duckdb-haskell/blob/main/duckdb-ffi/Setup.hs | 11:09:28 |
 maralorn | What exactly? That this is not just using pkg-config? | 11:52:58 |
 Teo (he/him) | At least it's not hard coding paths in the .cabal file | 11:56:03 |
| sterni | they search for the library and headers for no other reason than to fail with a “helpful” error message | 14:21:18 |
| sterni | this build may fail with Setup.hs and succeed if you delete it | 14:21:47 |
|  Collin Arnett changed their profile picture. | 15:23:55 |
 Daniel Firth | Doing a few benchmarks of GHC here. https://www.youtube.com/watch?v=kt2hM2uz8Hs | 21:13:09 |
 keypusher | Say I have 2 flakes A and B that basically are just haskell packages. B depends on A. If I use nix, it's quite the roundtrip to update A and utilize those changes in B. Someone hinted it's possible to circumvent nix and easily get changes to A while in a nix develop shell for B. Makes sense? | 21:45:30 |
| Alex | In reply to @keypusher:matrix.org
Say I have 2 flakes A and B that basically are just haskell packages. B depends on A. If I use nix, it's quite the roundtrip to update A and utilize those changes in B. Someone hinted it's possible to circumvent nix and easily get changes to A while in a nix develop shell for B. Makes sense? It's not entirely clear what you're asking or of what relevance Haskell or Nixpkgs are, but how about overriding flake B to use a different version of flake A? | 21:47:41 |
| keypusher | I'm getting at the timeconsuming roundtrip of getting a change in A availalbe in the "nix developer shell" of B. Atm I need to 1) make changes to A. 2) exit B's dev shell. 3) start B's dev shell that includes an implicit build of the A flake. 4) issue cabal build in B's devshell. | 21:52:09 |
| Alex | In reply to @keypusher:matrix.org
I'm getting at the timeconsuming roundtrip of getting a change in A availalbe in the "nix developer shell" of B. Atm I need to 1) make changes to A. 2) exit B's dev shell. 3) start B's dev shell that includes an implicit build of the A flake. 4) issue cabal build in B's devshell. You could exclude A from the devshell build by adding it to the packages list in haskellPackages.shellFor.
This naturally assumes that A's source is visible to B's Cabal project. | 21:55:51 |
| keypusher | A right. Yeah it could be different target (forgot the actual term). Like nix flake develop .#includeAInBuildOfB so to speak? | 21:59:58 |
| Alex | If you still want to keep the "A from devshell" version, then yes you could make this "fast" devshell a different one. | 22:01:20 |
| 4 Nov 2025 |
|  ncfavier changed their profile picture. | 23:55:13 |
| 5 Nov 2025 |
 tks_123 | I have a "nix develop" environment working fine for "cabal build". It links successfully to a custom static C library I have in the flake.nix | 07:35:24 |
| tks_123 | When running "cabal repl", why does it complain the dynamic library .so isn't found? This library is only static | 07:35:44 |
| tks_123 | * When running "cabal repl", why does it complain the dynamic library .so isn't found? The library is only static. (It's specified in extra-libraries in .cabal btw.) | 07:36:10 |
|  Supermuskox left the room. | 09:10:40 |
