| 30 Nov 2025 |
WeetHet | I don't see why nix3 CLI which is inherently flawed should stay in Lix | 19:13:50 |
helle (just a stray cat girl) | nix3 cli feels more thought out in terms of options and other bits, as someone who got introduced to nix after it was already in | 19:13:46 |
helle (just a stray cat girl) | though I get to probably fine comb the documentation vs the code reality, so will be able to support this feeling hopefully at some point | 19:14:18 |
WeetHet | If Lix wants a better CLI then nix3 is definitely not better | 19:14:22 |
helle (just a stray cat girl) | lix cli with actually full consistency when | 19:16:07 |
helle (just a stray cat girl) | (and yes I know we actually have some ideas for this floating around) | 19:16:23 |
just1602 | IMO the solution would be nix4 only if we actually deprecated the other two.
For the unified thing, you can create aliases but it could be good for UX to have a command that handle flake automatically if flake is enabled, etc
If we don't go that way, I'm totally fine with it, but we'll need really good documentation and tutorial to explain people how to properly and efficiently use our thing | 19:16:58 |
helle (just a stray cat girl) | pondering if someone should just prototype this as a pile of wrappers, see where consistency would strand, etc | 19:18:51 |
WeetHet | I'm not against a better nix cli then nix2, nix3 is just not it | 19:19:11 |
helle (just a stray cat girl) | might not be the best solution, but sometimes throwing some bad code in a standalone setting shows quickest what the right UX should be | 19:19:25 |
WeetHet | I might just be used to it but I don't think nix2 is that bad | 19:30:51 |
WeetHet | It can use some improvement (like changing/allowing to set up different default log format) but overall it works with files(-ish) and expressions/attributes and does exactly what it is supposed to do | 19:33:27 |
WeetHet | One thing it's missing badly is a native concept of shells leading to having to work around it and having a dependency on nixpkgs | 19:35:42 |
WeetHet | One would assume that a new CLI should address this first and foremost to close a hole leading to a dependency on the internal nixpkgs logic and propose a new structured way to approach devshells | 19:37:23 |
WeetHet | Nix3 doesn't do that. | 19:37:29 |
helle (just a stray cat girl) | one of the interesting questions with that is, well, this can be done with nix code, so should this just be a smaller external thing (possibly maintained in conjuction with lix), mostly independent of nixpkgs | 19:50:08 |
raitobezarius | In reply to @weethet:catgirl.cloud What's the point in leaving nix3 CLI in Lix if it would be there strictly so that an external plugin would work The point is doing it progressively | 19:59:36 |
raitobezarius | And anyone can add a plugin | 19:59:44 |
raitobezarius | We might enable nix3 CLI to have a workable installable syntax without Flakes but we don't know yet where we will get | 20:00:16 |
raitobezarius | In reply to @weethet:catgirl.cloud Nix3 doesn't do that. We already agree to this and there's a nix4 CLI project | 20:01:05 |
raitobezarius | That's not reason enough to bomb nix3 :p | 20:01:15 |
just1602 | I'm wondering if there's gonna be a way for nix4 cli to not be written in C++, so we could use something like clap 😃 | 20:19:43 |
raitobezarius | I don't believe it, RPC for CLI is way too far | 20:24:01 |
WeetHet | Can't we use FFI instead? | 20:45:30 |
WeetHet | We already do for :doc in repl? | 20:45:45 |
raitobezarius | Exceptions and Rust is not going to be funny | 21:07:29 |
raitobezarius | In reply to @weethet:catgirl.cloud We already do for :doc in repl? It's not really FFI, it's cheating | 21:35:41 |
Jules Lamur | Hi, does anyone know how to run nixcpp/lix in a podman rootless container (no caps and /proc masked)? I'll try to dig into that but I thought somebody may have had the same usecase already :) | 21:37:56 |
raitobezarius | With sandbox or without? | 21:38:37 |
hexa | possibly https://github.com/DavHau/nix-portable | 21:38:38 |