| 3 Nov 2025 |
 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 |
| Supermuskox joined the room. | 09:37:13 |
 sterni | what version of GHC? | 10:06:54 |
| sterni | I think for 9.4 this works, but in general it is not to be expected. You need to coax the rts linker into loading a shared archive which it doesn't necessarily like because it's tricky. dlopen of course only works for shared objects which is the normal way | 10:08:33 |
| sterni | (Haskell static archives/object files is not a problem, but arbitrary ones) | 10:08:56 |
