| 26 Mar 2026 |
 boop-north | https://docs.lix.systems/manual/lix/stable/package-management/basic-package-mgmt.html and this if you are intrested | 08:52:49 |
| boop-north | you could absulutely use lix as a purely cli package manager, thats what I've been doing since 2024 and I am just starting to use the other stuff like home-manager | 08:53:44 |
| boop-north | * https://docs.lix.systems/manual/lix/stable/package-management/basic-package-mgmt.html and this if you are intrested (its even a shorter read) | 08:55:41 |
| boop-north | is it normal for lix to take a good minute to fetch a package? | 09:57:16 |
| boop-north | I fixed the daemon btw, wait now that I think about it, is it because the daemon initializes before I want to use nix shell? or maybe it itself is daemon? maybe selinux is not the problem at all. | 10:01:37 |
| boop-north | ` | 10:03:26 |
| boop-north | [Unit]
Description=Arti Tor Proxy
After=network.target
[Service]
Type=simple
ExecStart=/nix/var/nix/profiles/default/bin/nix-shell -p arti --run "arti proxy"
Restart=on-failure
| 10:03:40 |
| boop-north | I want something like this, maybe there is a nix way? I dont even have a flake yet on my system (I've just started using lix more like lix after 2 years) | 10:04:55 |
| boop-north | This is aarch64 fedora 43 if it matters | 10:05:33 |
 EsperLily [she/her] | rec-set-merges as described in the manual is a bit odd. it indicates that it’s fine to merge two attrsets if both are marked rec. and it links to an issue for further description. that issue implies that { foo = { a = 1; }; foo = { b = 2; }; } is code that would be accepted today. i’m lying in bed on my phone so i can’t check but my recollection is that this attrset would be rejected for duplicating the foo key, that you can only duplicate it like that if you’re using the syntax sugar form foo.a = 1;. if my recollection is right that the unsugared form disallows duplicates then there is no way to have both merged attrsets be rec.
also, neither the manual nor the linked issue describe the actual thing that the separate issue on the Lix issue tracker described (https://git.lix.systems/lix-project/lix/issues/350), which is that the real problem is with code like { foo = rec { b = 1; }; foo.c = b; } where the desugaring makes b in-scope even though it doesn’t look like it should be. i think the manual should probably link to the Lix issue instead of the CppNix one. also the manual’s link to the CL is a 404
| 10:26:39 |
 raitobezarius | thank you so much for the feedback | 10:29:10 |
| raitobezarius | i'd recommend installing arti in a profile and referring to its path in the profile | 10:29:58 |
| EsperLily [she/her] | and rec-set-dynamic-attrs in the manual still doesn’t actually make a good argument for why the behavior of that is considered bad. it makes perfect sense to me that a dynamic attr in a rec set is evaluated after the others (e.g. that the ability to reference keys from the recset in the dynamic attribute key demands that it be evaluated after) and also that the dynamic attribute itself doesn’t have recursive semantics, as the resulting key requires evaluating an expression and it doesn’t exist textually in the source. having the dynamic attribute have recursive semantics would be rather surprising. i am actually mildly surprised that rec { ${ “a” } = 1; b = a; } does in fact work, but in that case the attribute isn’t actually dynamic it just uses the same syntax (which is to say, the key does in fact exist textually in the source and can be statically known without actually evaluating anything) and so i don’t think it’s a problem that this works | 10:32:24 |
| boop-north | Nix Shell is done on purpose, so I stay up to date each time I run arti. | 10:33:02 |
| raitobezarius | so i think your shell is the best way to do it | 10:33:31 |
| raitobezarius | depending on your network conditions and performance, 1 minute seems reasonable for the launch of the thing | 10:33:50 |
| boop-north | also when I did that, it didnt work either | 10:34:17 |
| boop-north | disabling selinux DID make it work | 10:34:25 |
| boop-north | I think it being under /nix makes selinux trip out | 10:34:40 |
| boop-north | * disabling selinux DID make it work though | 10:34:48 |
| raitobezarius | yeah, selinux and nix is somewhat an art | 10:35:28 |
| boop-north | if it is my network then its fine, I am in my uni wifi so I guess its expected | 10:35:29 |
| raitobezarius | i don't know much in those areas | 10:35:31 |
| raitobezarius | yeah, i think you're paying eval costs + some cache hits/misses costs in the ideal path | 10:35:59 |
| raitobezarius | (but unavoidable if you want the "latest version" according to the nixpkgs evaluation) | 10:36:20 |
| boop-north | unrelated, they brought a horse to my uni, it is exploring the garden currently | 10:36:29 |
| boop-north | 
Download IMG-20260326-WA0002.jpeg | 10:37:15 |
| EsperLily [she/her] | in fact, i’m pretty sure that if dynamic attributes did have recursive semantics then i could write an expression that is undecidable. i could write a pair of dynamic keys that would form a dependency loop, and i could write a dynamic key (or maybe a pair of them) that would cause a contradiction in evaluation, a key that evaluates to a given string if and only if it doesn’t evaluate to that string. dynamic attributes in a recset must be non-recursive. and that’s fine. i’d rather have non-recursive dynamic attributes then forbid having the dynamic attributes | 10:39:56 |
| EsperLily [she/her] | and with that i’m going to sleep. ping me if you want any more feedback tomorrow, otherwise i’ll probably forget about this in the morning | 10:41:21 |
| EsperLily [she/her] | (fwiw i’m guessing that none of my current code will actually be impacted by banning dynamic attrs in recsets, since i try to use recsets sparingly, but i just don’t like the idea that i might some day try to add a dynamic attribute to an existing attrset and be told i can’t do that as the set is recursive, even though i wasn’t expecting the dynamic attribute to be recursive too) | 10:43:04 |
