| 28 Nov 2025 |
 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 |
 david | Hrm, `nix upgrade-nix` is failing with permissions issues on trying to open `/nix/var/nix/profiles/default.lock` | 22:53:10 |
| david | Having trouble finding a fix/workaround, anyone have suggestions? | 22:53:27 |
| david | "ask for help so you can solve it yourself" works yet again | 22:59:56 |
| david | `sudo nix` could not find `nix` but if I sourced the profile from a root shell upgrade-nix worked fine | 23:07:44 |
| david | Still maybe a potential issue but idk. Specifically it failed while trying to uninstall the old version of Lix (for reference, 1.93 -> 1.94) | 23:08:32 |
| 29 Nov 2025 |
 raitobezarius | In reply to @david:lenfesty.ca
Still maybe a potential issue but idk. Specifically it failed while trying to uninstall the old version of Lix (for reference, 1.93 -> 1.94) Can you open an issue? Thanks! | 00:08:59 |
