| 24 Feb 2026 |
 K900 | https://github.com/NixOS/nix/commit/3180671cabeb6a6010057770731e12761ed5666c cppnix broke flakes again | 13:52:16 |
| K900 | We could cherry-pick | 13:52:27 |
| K900 | Also the nix profile add thing from the other day | 13:52:37 |
 raitobezarius (DECT: 7248) | man | 13:52:39 |
| K900 | I think it's fine to pick these small-ish changes that should merge cleanly into the migration | 13:53:01 |
| raitobezarius (DECT: 7248) | Yes, but this change is non trivial from a libexpr perspective | 13:53:16 |
| raitobezarius (DECT: 7248) | Now url Value have context strings? | 13:53:26 |
| K900 | Yeah that one might be too much | 13:53:34 |
| raitobezarius (DECT: 7248) | I need to think | 13:53:47 |
| K900 | I was thinking about the nix profile add one more | 13:53:47 |
| raitobezarius (DECT: 7248) | the nix profile add is controversial because this change has no raison d'etre and I understand that some folks in the team are getting really pissed off by this irresponsible behavior | 13:54:41 |
 delroth | this was actively being discussed on zulip yesterday fwiw if you don't follow that medium | 13:54:47 |
 emily | also, lists already have short-circuiting equality with a canonical ordering | 13:55:18 |
| emily | so making attrsets inconsistent with that seems gratuitous | 13:55:29 |
| delroth | really the irresponsible behavior is 3rd party software deciding to build on an experimental interface, no? | 13:55:34 |
| raitobezarius (DECT: 7248) | yes | 13:55:47 |
| raitobezarius (DECT: 7248) | hence: https://github.com/nix-community/home-manager/issues/8786#issuecomment-3951682232 | 13:55:54 |
| delroth | nice, that was roughly my take on this whole thing as well | 13:56:25 |
 Qyriad | In reply to @raitobezarius:matrix.org
the nix profile add is controversial because this change has no raison d'etre and I understand that some folks in the team are getting really pissed off by this irresponsible behavior "add" probably does make some sense over "install" since "install" implies a lot of things. but meh.thiho | 13:56:29 |
| raitobezarius (DECT: 7248) | I don't really care about the details of the change in itself, I agree that a rename like that is unproblematic | 13:57:18 |
| Qyriad | In reply to @raitobezarius:matrix.org
the nix profile add is controversial because this change has no raison d'etre and I understand that some folks in the team are getting really pissed off by this irresponsible behavior * "add" probably does make some sense over "install" since "install" implies a lot of things. but meh. | 13:57:31 |
| raitobezarius (DECT: 7248) | I care about the consequences for 3rd party software which have stability commitments which are failing to uphold them because they rely on this because people tells them nix-command is defacto stable but it's actually not because someone actually did use the unstable contract to change things | 13:57:50 |
| raitobezarius (DECT: 7248) | I don't want to adopt blindly the change and give the signal that it's OK to do this sort of things in the future even more too | 13:58:43 |
| Qyriad | There is a problem though in that nix-env and nix profile can't be used together | 13:59:14 |
| Qyriad | You can't just stop using nix profile and go back to nix-env without deleting the profile | 13:59:30 |
| raitobezarius (DECT: 7248) | This seems like a problem we need to address | 14:00:27 |
| Qyriad | Ah, except for nix-env --set. Since that has nothing to do with the profile's manifest and is really about profile generation management than the profile itself | 14:04:09 |
| emily | to put it another way: set1 == set2 really ought to be equivalent to attrNames set1 == attrNames set2 && attrValues set1 == attrValues set2. you can always express this in the language and if we model the current behaviour as nondeterministic there's always a conceivable execution trace that matches these semantics. so it doesn't make sense to make equality stricter than that interpretation, which is consistent with lists, consistent with the existing builtins on attrsets, and optimal in terms of runtime performance of the comparison loop. thoughts, @piegames:flausch.social ? | 15:14:44 |
| emily | the other reasonable alternative is to make it equivalent to map (name: [ name set1.${name} ]) (attrNames set1) == map (name: [ name set2.${name} ]) (attrNames set2) but this is:
- I think inevitably strictly slower in terms of runtime perf because there are cases where you will recurse into expensive thunks that the other variant never will
- more difficult to express in terms of in-language primitives
- less compatible - for every program that returns true or false from such a comparison, the other variant will also return that value, but this variant will abort/loop forever/throw strictly more often
both of them are entirely consistent with "angelic" choice of nondeterministic comparison orderings, but I don't think the interleaved variant has any merits
| 15:21:32 |
| emily | other reasons comparing names separately makes more sense:
- consistent with lists,
[ abort abort ] != [ abort ] compares lengths before values already, and list lengths are analogous to attrset key sets
- indeed the interleaving version can't legitimately even short-circuit on the number of names without complicating semantics because of
{ a = abort; } != { b = abort; c = abort; } -- whereas if you compare names first, you can legitimately do that short circuit because attr name set comparison happens before any thunks are forced
| 15:44:34 |
