| 14 Feb 2025 |
 llakala | In reply to @samrose:matrix.org
Yes, it was my impression based on following along here from time to time, building Lix, looking at the code, etc that the quality is higher. But still thought could be worth seeing what people here have to say instead of just my interpretation my reason for choosing Lix as a user (and I expect many people have similar reasons) is that CppNix had a long-standing bug with no effort being put into fixing it. Lix, sanely being forked from CppNix 2.18, was able to avoid this. I have my own personal opinions on the actions of members of the CppNix team, but the truth is Lix functions for me and CppNix does not. | 22:57:49 |
 samrose | I had heard a lot about this. I had not personally run into it. But I am also not building either all of nixpkgs, or combinations of things that surface the bug(s). But this is certainly important information for people who are comparing these things from stability etc points of view. | 23:24:47 |
 piegames | In reply to @samrose:matrix.org
so, Why should someone use Lix vs Nix? Rainbow-colored pepe frog, got it. Lix is faster and has better error messages, and will improve even more on both in the next releases | 23:26:42 |
| piegames | That's my one-sentence selling pitch, at least | 23:27:04 |
| llakala | i mean, my personal problem was that nix flake update literally didn't work at all | 23:52:25 |
| llakala | which was because of this issue | 23:53:14 |
| llakala | but nix bugs have resulted in the fileset library from being banned from nixpkgs because they have to constantly work around these issues | 23:54:30 |
| 15 Feb 2025 |
 Charles |
error: store path 'hjldl7yfkl05a80c0wy1ahx3xjjpnvas-y5k5jpiw0cvbamngxcxpab7c3rlq810p-g7wq31narlyzhrzwfs23yp81ldylcyqs-s86isjmpm62zbr4iaygkhzm4san06yan-ak6vn51qcjpnmm6ni4r7viyzivpmwwm1-mvp801hkmzvinxpzlv856vfhf5ny2i5h-3b053s964xqd59yv6v1ndnmhwqimx2cx-5iavd1h6ijj0279ag9y8lxypw558m0x1-source' has a name longer than 211 characters
lol, never seen this one before
| 00:27:47 |
| Charles | my code here would probably recurse infinitely if there wasn't a length check lol | 00:29:13 |
| Charles | hm, this is probably a stupid question, but can the keys/names in an attribute set be of any type other than string? or are only strings allowed? | 01:03:31 |
| Charles | { 4 = 7; } doesn't work for example and i've never seen anything other than strings for keys, so i would assume they have to be strings, but i thought i'd double check | 01:04:26 |
 mjm | they are always strings | 02:13:53 |
 Whovian9369 | Redacted or Malformed Event | 02:27:23 |
| Whovian9369 | * Hey gang, what are the suggested ways to set up a Digital Ocean droplet? I know that I could use nixos-infect, nixos-anywhere or "${nixpkgs}/nixos/modules/virtualisation/digital-ocean-{config,image}.nix but I can't really decide on what I should attempt. | 02:27:41 |
| Whovian9369 | (Ah this may not be the best channel for the question, sorry!) | 02:30:57 |
 aloisw | In reply to @llakala:matrix.org
but nix bugs have resulted in the fileset library from being banned from nixpkgs because they have to constantly work around these issues In fairness, this bug has not been fixed in Lix either as far as I know. | 05:58:40 |
 K900 | The fun thing about that particular bug is that it's impossible to fix without changing existing semantics | 06:15:53 |
| K900 | You could even argue there is no bug, just extremely unexpected behavior | 06:16:14 |
| K900 | Because the behavior is consistent | 06:16:50 |
| K900 | It's just completely insane | 06:16:55 |
| aloisw | In reply to @k900:0upti.me
The fun thing about that particular bug is that it's impossible to fix without changing existing semantics I don't think "code behaves differently when evaluated in a "chroot" store" are existing semantics that are worth preserving. | 06:17:33 |
| Charles | clearly the solution is new fixed builtin functions with ' suffixed to their names | 06:17:53 |
| K900 | In reply to @aloisw:julia0815.de
I don't think "code behaves differently when evaluated in a "chroot" store" are existing semantics that are worth preserving. I mean | 06:18:21 |
| Charles | or perhaps you could pull from php naming conventions because it's done this kind of thing a lot | 06:18:23 |
| K900 | I'm not saying it shouldn't be changed | 06:18:38 |
| K900 | I'm just saying the situation is more complicated than just "bug not fixed" | 06:18:57 |
| K900 | In practice I think we should go ahead and just break it because it's absolutely impossible for the old behavior to actually be useful for anyone ever | 06:19:22 |
| Charles | i was gonna ask what your take would be | 06:19:40 |
| K900 | But it is still a compatibility break and should be handled with care | 06:21:31 |
| aloisw | In reply to @k900:0upti.me
I'm just saying the situation is more complicated than just "bug not fixed" I don't think it is actually, fixing the bug would just make a behaviour that is already present (namely in the non-"chroot" case) consistent. | 06:21:55 |
