Lix Development | 422 Members | |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 140 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Feb 2026 | ||
| 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 | |
In reply to @raitobezarius:matrix.org* "add" probably does make some sense over "install" since "install" implies a lot of things. but meh. | 13:57:31 | |
| 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 | |
| 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 | |
There is a problem though in that nix-env and nix profile can't be used together | 13:59:14 | |
You can't just stop using nix profile and go back to nix-env without deleting the profile | 13:59:30 | |
| This seems like a problem we need to address | 14:00:27 | |
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 | |
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 | |
| the other reasonable alternative is to make it equivalent to
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 | |
| other reasons comparing names separately makes more sense:
| 15:44:34 | |
| I'll put a summary of this up on the Nix PR in a few hours since this is getting verbose :) | 15:49:55 | |
but I firmly believe attrNames set1 == attrNames set2 && attrValues set1 == attrValues set2 is the right semantics on both practical and theoretical grounds (and we should fix anywhere Nixpkgs still relies on pointer equality dodging type errors/aborts/throws/infinite loops and then move towards not doing that by default) | 15:51:51 | |
| Okay | 16:23:57 | |
| 25 Feb 2026 | ||
| 16:55:51 | ||
| 21:51:40 | ||
| 26 Feb 2026 | ||
| 14:01:48 | ||
| 23:44:11 | ||
| 27 Feb 2026 | ||
| 20:14:32 | ||
| 20:36:06 | ||
| 16 May 2024 | ||
| 13:54:49 | ||
In reply to @lunaphied:lunaphied.meThe other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 | |
| we are not in any rush 🙂 | 17:20:53 | |
| Would it help to also test out the existing Lix code and try to find issues/bugs etc? | 17:23:21 | |
| absolutely | 17:23:41 | |
| 17:23:48 | |
| it's pitiful | 17:24:10 | |
| heh | 17:24:16 | |
| expanding it is cool | 17:24:23 | |
| writing new tests for builtins which are not tested | 17:24:30 | |