| 28 Nov 2025 |
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 |
| @conformally:matrix.org left the room. | 11:41:40 |
Arian | I think I found some weird daemon protocol incompatibility between nix and lix | 12:39:02 |
Arian | % nix flake check --eval-store auto --store ssh-ng://altra --system aarch64-linux
error: cannot build missing derivation '/nix/store/s131lvrb3pqysw22nl0lmq8sbdflpwfc-vm-test-run-spire-join-token.drv'
from a 2.24.12 evaluator to a 1.94 remote builder.
I’m pretty certain this used to work on 1.93
| 12:39:54 |
Arian | But this is probably in the “we dont care” territory. lemme try with lix and lix | 12:41:47 |
raitobezarius | I wouldn't want to try hard to debug an issue that could be not on our side | 12:44:36 |
raitobezarius | If you have more data and/or a reproducer, feel free to throw an issue at me, no promise tho | 12:44:57 |
raitobezarius | If it's a Lix/Lix issue, of course, this is prioritized | 12:45:07 |