| 28 Nov 2025 |
 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 |
| 522 it/its ⛯ΘΔ | i do think for machine resolution of versions you don't need semver, you only need a major version that you can bump (which, yeah, you can use branches for that) | 11:52:07 |
| 522 it/its ⛯ΘΔ | most of semver is for humans reading it | 11:52:29 |
| toonn | It's also humans writing it so it's not infallible. API inspection would be pretty cool. | 12:15:54 |
| goldstein | API inspection for Nix is hard because of laziness
you don’t know which subexprs you can even touch to inspect | 12:26:12 |
| goldstein | and also any behind a lambda is ~completely opaque I think | 12:26:36 |
| toonn | It's hard in any language TBH. | 13:44:53 |
