| 24 Jan 2026 |
neindochoh! / Seti (they/them) | * | 09:48:05 |
Acid Bong | In reply to @milo:wiro.world
lix fmt doesn't behave the same as nix fmt when invoked with no arguments.
nix fmt passes the project root directory (the one parent of the flake.nix) as the default argument. Whereas, lix fmt simply acts as a nix run .#formatter.
Is this intentional? If so, what is the reason? If not, could I volunteer a PR to match nix's behaviour?
btw, what are Lix and Nix versions you're having? | 09:54:35 |
niko ⚡️ | In reply to @milo:wiro.world
lix fmt doesn't behave the same as nix fmt when invoked with no arguments.
nix fmt passes the project root directory (the one parent of the flake.nix) as the default argument. Whereas, lix fmt simply acts as a nix run .#formatter.
Is this intentional? If so, what is the reason? If not, could I volunteer a PR to match nix's behaviour?
I believe nix changed that behavior like a year ago at this point | 11:19:50 |
niko ⚡️ | There’s been numerous warnings about that behavior changing soon at least | 11:20:06 |
niko ⚡️ | This is also why it’s advised to use nixfmt-tree for the formatter output | 11:20:26 |
llakala | In reply to @niko:nrab.lol This is also why it’s advised to use nixfmt-tree for the formatter output i have nixfmt enforced in CI, and rather than using nixfmt-tree, i just use a glob on all the files on the directory | 17:45:55 |
llakala | modern problems require modern solutions | 17:46:02 |
sterni | I was messing with this (https://git.lix.systems/lix-project/lix/src/commit/e9cccd47e216f0b90d68e471162a651176feb5b4/lix/libstore/build/derivation-goal.cc#L918-L931), but can't seem to see any effects of it. Is this exception somehow propagated from the daemon to the client, so I need to deploy a separate daemon or am I missing something? | 18:33:01 |
K900 | Yes, it is | 18:34:28 |
K900 | That's exactly what is happening | 18:34:33 |
K900 | This is fully formed on the daemon side and then passed to the client as one big string | 18:34:46 |
sterni | ah that's already helpful for understanding what's going on. is there a good setup for working on the daemon side, then? | 20:19:55 |
niko ⚡️ | If you run lix as root you can bypass talking to the daemon | 21:31:10 |
niko ⚡️ | It used to be the default, inherited from nix, but nowadays I believe lix always talks to the daemon unless specified otherwise | 21:31:36 |
niko ⚡️ | Alternatively you can run a daemon with a different store directory and connect to that instead | 21:32:38 |
KFears (they/them) | In reply to @niko:nrab.lol If you run lix as root you can bypass talking to the daemon Oh god | 21:43:21 |
KFears (they/them) | Is this the CppNix way of making Nix work in containers? | 21:43:46 |
sterni | it's just single user nix | 21:56:17 |
| 13 May 2024 |
| zrsk joined the room. | 13:37:30 |
| dariof4 joined the room. | 14:16:05 |
| abbe joined the room. | 14:42:22 |
mjm | lix is now in nixos-unstable, what's the best way to use it in a NixOS config? | 15:47:41 |
K900 | nix.package = pkgs.lix | 15:47:54 |
K900 | Probably | 15:47:58 |
K900 | Or just keep using the module | 15:48:02 |
puck | you can use nix.package = pkgs.lix; if you want; but using the overlay will guarantee more updates (tho less binary cache) | 15:48:44 |
mjm | well, the module/overlay doesn't easily support using the one from nixpkgs | 15:48:44 |
mjm | i do want more binary cache | 15:49:21 |
mjm | yeah i guess i'll just do nix.package then | 15:50:43 |
raitobezarius | to have binary cache and HEAD, we will probably need to track the channels and bolt a lix on there and rebuild with our own CI then push in our binary cache | 17:33:17 |