| 27 Nov 2025 |
 WeetHet | Why is it not behing nix-command | 12:44:55 |
| WeetHet | Why is there no nix-repl that would work like a normal nix2 program? | 12:45:13 |
 toonn | It was always like this, there was no repl before nix repl. | 12:46:37 |
| WeetHet | Would making it dependent on nix-command being enabled and add a proper nix-repl, or would that be considered breaking? | 12:52:10 |
| toonn | What would be the benefit? Other than satisfying a desire for consistency? | 12:55:09 |
|  @sntx:matrix.org left the room. | 13:36:10 |
 goldstein | Atemu unflake is now public! https://discourse.nixos.org/t/unflake-flake-dependencies-for-non-flake-projects-and-a-way-to-stop-writing-follows/72611 / https://codeberg.org/goldstein/unflake | 18:46:41 |
 aloisw | In reply to @weethet:catgirl.cloud
Why does nix repl follow the structure of nix-command while not being experimental? Was it always like that? Is this yet another cppnix historical artifact? Does this mean that nix-command is impossible to remove without a breaking change? Yes, historical artifact. Actually there was a separate nix-repl at some point but it got merged into the tree. | 19:49:53 |
 vringar | Hey,
I'm currently trying to set up nixos on ZFS by following the nixos.wiki/wiki/ZFS guide from the NixOS installer image
However, the image doesn't have ZFS kernel module active, the /etc/nixos/configuration.nix is read-only, so I can't add it but zpool create only works with the kernel module present.
How can I best bootstrap myself into an environment with the ZFS kernel module present so I can configure the internal disk?
My first thoughts are remounting the root file system to be rw or to install NixOS to ext4 on the primary disk, then boot there, follow the tutorial from there and later nuke the ext4 partition and reintegrate it into the zpool | 19:45:18 |
 helle (just a stray cat girl) | I mean I kind of prefer the nix-command structure personally, but I haven't know nix without it | 20:00:17 |
 raitobezarius | The NixOS installer image has ZFS on the LTS kernel | 20:06:56 |
| raitobezarius | Simply reboot in the LTS kernel and you should have ZFS I think? | 20:07:03 |
| vringar | In reply to @raitobezarius:matrix.org
Simply reboot in the LTS kernel and you should have ZFS I think? Ahhh, my bad
Didn't consider that when choosing the installer image.
Thanks! | 20:12:03 |
| toonn | Is unflake flake-compat on steroids? | 23:12:51 |
| 28 Nov 2025 |
|  yqrashawn joined the room. | 00:35:31 |
 antifuchs | Oh neat, unflake looks like fun, but way different from flake-compat. The latter tries to work with the flake as written; unflake looks like it rewrites your source tree | 04:43:00 |
| goldstein | flake-compat works with flake.lock, so it uses built-in resolver
unflake doesn’t interact with flake.lock at all. it resolves dependencies internally, unifies them and produces its own lockfile (or integrates with npins for locking) | 11:04:01 |
| goldstein | not sure what do you mean by “rewrite your source tree”. the only files unflake writes is unflake.nix and (if npins integration is enabled) npins/sources.json | 11:04:30 |
| goldstein | * not sure what do you mean by “rewrites your source tree”. the only files unflake writes is unflake.nix and (if npins integration is enabled) npins/sources.json | 11:04:41 |
| toonn | So it ignores flake.lock altogether? | 11:07:00 |
| goldstein | yeah, it doesn’t read any flake.lock files | 11:07:34 |
| helle (just a stray cat girl) | distinctly both an upside and a downside I guess | 11:07:59 |
| goldstein | yeah, kinda
the big question is whether we actually need transitive dependency locking
I have a feeling that we don’t, and the ecosystem is so used to writing .follows that we actually already don’t really fully lock transitive dependencies, but we lose some reproducibility, obviously | 11:09:59 |
| toonn | I recently ran into a flake that didn't have an accompanying flake.lock, flake-compat couldn't handle it. It supports only lockless flakes that don't have any inputs except for self, AFAIU. So unflake would've probably helped in that instance. | 11:10:02 |
| helle (just a stray cat girl) | I mean I have some stuff that needs careful poking at when updating | 11:10:37 |
| goldstein | you still have top-level lockfile in any case (it’s just not called flake.lock) and you can upgrade individual dependencies with npins | 11:12:00 |
| helle (just a stray cat girl) | yeah, I am currently using npins for those, so it is not a huge worry for that | 11:12:31 |
| goldstein | I’m planning on adding granular updates in unflake’s native lockfile too (so you don’t need npins for that; there’re some pain points with npins integration), but it’s not there yet | 11:13:51 |
| goldstein | * I’m planning on adding granular updates in unflake’s native lockfile too (so you wouldn’t need npins for that; there’re some pain points with npins integration), but it’s not there yet | 11:14:34 |
 Jassuko | I've always felt that the flake locking concept is managed "wrong way around". I would like to specify a clear exception when something is brittle or broken and needs to lock into a specific nixpkgs or other dependency version instead of following the top-level nixpkgs choice. The default should be to follow the parent whenever possible. -_- | 11:22:27 |
