| 25 Aug 2025 |
 maralorn | Yeah. I would expect this to just work(TM) as a default.nix with nix-build. | 15:52:52 |
 sterni (he/him) | Pierre Thierry: As I've outlined in my response in the thread. developPackage behaves differently based on whether IN_NIX_SHELL is set. direnv presumably inherits this variable when exporting the variables set in the shell environment. nix-build does not unset this environment variable. If you want to continue using developPackage, I'd recommend manually unsetting IN_NIX_SHELL after the use nix directive in .envrc | 16:09:49 |
| sterni (he/him) | This is more or less why I wouldn't recommend using developPackage anymore. It tries to do the right thing magically, but is not very flexible. Also nowadays, code relying on IN_NIX_SHELL (see lib.inNixShell) has become rare (since there is no equivalent in pure-eval, flakes etc. which grow increasingly popular), so users no longer expect this behavior. | 16:11:12 |
| sterni (he/him) | https://nixos.org/manual/nixpkgs/stable/#function-library-lib.trivial.inNixShell now that's a bad docstring | 16:27:41 |
| sterni (he/him) | https://github.com/NixOS/nixpkgs/issues/436814 | 17:49:55 |
 emily | it looks like nothing but Haskell uses it? | 18:06:05 |
 mra | Unfortunately, this doesn't seem to straight-up work? If I look in the sources from the template: https://github.com/clash-lang/clash-starters/blob/main/simple-nix/nix/sources.json, and then copy the link to the version of nixpkgs that they used into my flake, I just get a new error: "Package ‘clash-prelude-1.6.6’ in [...] is marked as broken, refusing to evaluate.". Would it be possible to just copy the nix directory into my project, and then import ./nix/nixpkgs.nix or something to use as the nixpkgs input for my flake? | 19:22:03 |
| maralorn | Oh, apparently they have a ton of overlays there to fix stuff. | 20:32:19 |
| maralorn | Yes, somehow getting the niv folder in there should work. But flakes is kinda meant to be an alternative to nix. | 20:33:04 |
| maralorn | Translating pins from upstream into a different dependency mechanism to track dependencies is kinda going a bit against the grain. | 20:33:42 |
| maralorn | * Translating pins from upstream into a different mechanism to track dependencies is kinda going a bit against the grain. | 20:33:54 |
| 26 Aug 2025 |
| mra | Hm, maybe I'm being a bit stupid trying to turn this into a flake. I guess I could just keep the existing nix stuff from the template? I'm just mildly annoyed about not being able to use nix develop. I thought that I would just be able to do something like inputs.nixpkgs = import ./nix/nixpkgs {};, in my flake but if I do this I get the error "expected a set but got a thunk", so I guess I've misunderstood something? | 02:54:59 |
| mra | Sorry if it's not obvious, but I'm not exactly an expert with Nix :P | 02:55:14 |
| maralorn | In reply to @morgan.arnold:matrix.org
Hm, maybe I'm being a bit stupid trying to turn this into a flake. I guess I could just keep the existing nix stuff from the template? I'm just mildly annoyed about not being able to use nix develop. I thought that I would just be able to do something like inputs.nixpkgs = import ./nix/nixpkgs {};, in my flake but if I do this I get the error "expected a set but got a thunk", so I guess I've misunderstood something? Well. The problem causing your error message is that flakes only look like nix but only a subset is allowed. | 07:09:25 |
| maralorn | The problem from what I can tell is that the template uses multiple overrides to fix the build not just pinning nixpkgs. That's why you still encountered an error when you pinned the correct nixpkgs. | 07:10:13 |
| maralorn | The old style equivalent to nix develop would be nix-shell | 07:11:09 |
| 27 Aug 2025 |
 Artem | Thanks guys for posting all the updates on the 9.8->9.10 PR. Very informative and helpful for explaining how the many processes work. ❤️ | 00:39:27 |
|  Thibaut joined the room. | 13:35:37 |
| Thibaut | Hello! Is this the space to ask for a package update? I am interested in the dhall packages 🙏 | 13:39:23 |
 toonn | Thibaut: Aren't they part of Stackage? | 13:42:26 |
| Thibaut | I wasn't sure what was Stackage reading the nixpkgs stuff, indeed it is!
I guess it is normal that the stackage version is different from the last github's release? apparently it is, 1.42.2 matches github's version 23.1.0, so it looks up to date? | 13:46:22 |
| toonn | Thibaut: It depends on the Stackage snapshot. But Nixpkgs is more or less a recent Stackage snapshot with everything else filled in from Hackage. | 13:51:16 |
| toonn | It is geared towards supporting Haskell packages in Nixpkgs rather than Haskell development. | 13:51:44 |
| toonn | For development without the goal of packaging for Nixpkgs, I'd recommend simply using Cabal or Stack as you would on any other system. | 13:52:43 |
| Thibaut | Thanks. I understand now 👍️ | 13:52:45 |
| Thibaut | I just use the dhall tools so it's fine for me | 13:53:01 |
| 28 Aug 2025 |
 bglgwyng | It seems haskell.nix doesn't handle private repository in cabal.project(repository ... stanza) correctly | 06:22:32 |
| bglgwyng | It tries to download the package while building which leads the build to failure | 06:23:00 |
| bglgwyng | * It tries to download packages from the private repository while building which leads the build to failure | 06:23:15 |
| maralorn | bglgwyng: The haskell.nix maintainers don’t follow this channel very actively I think. | 08:27:12 |
