| 27 Nov 2025 |
 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 |
| goldstein | yeah, hence unflake
it follows based on input spec, so if someone specifies e.g. a specific commit or a different branch, it’ll get that, but otherwise everything will be unified | 11:23:27 |
| Jassuko | (but flakes feel like writing java anyway, so...) | 11:23:26 |
| goldstein | * yeah, hence unflake
it follows based on input spec, so if someone specifies e.g. a specific commit or a different branch, they’ll get that, but otherwise everything will be unified | 11:23:42 |
 522 it/its ⛯ΘΔ | mhm. though that being said, you don't want to force anything to use a breaking change. but flakes don't really have a notion of versioning or breaking change so you can't do that
i think the best situation would be to unify minor changes, but duplicate for major changes | 11:30:05 |
| goldstein | you can kinda use git tags/branches for versioning | 11:31:16 |
| goldstein | and it feels like somewhat of a norm in the ecosystem, since no one likes when nix flake update breaks stuff | 11:31:42 |
| 522 it/its ⛯ΘΔ | right. so "completely ignore dependency's flake.lock, always use the latest version of a given branch (and record that in your flake.lock)"? | 11:34:16 |
| goldstein | yeah, basically, except unflake doesn’t call its lock flake.lock
it either locks via npins or writes commit + nar hashes into unflake.nix | 11:36:04 |
| toonn | Jassuko: That sounds a bit like you want constraint resolution. TBF that is a way more complicated model of dependency specification. | 11:43:39 |
| goldstein | ideally I want flakes to have semver versions lol
but I believe that “same branch/tag ≈ semver compatible” would probably hold in most cases and we can maybe build escape hatches for when it doesn’t | 11:46:14 |
| goldstein | (this is already the assumption baked in the widespread practice of writing .follows to avoid duplication) | 11:46:52 |
