| 30 Nov 2025 |
 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 |
| Jules Lamur | yeah sorry forgot about the important part: with the sandbox :) | 21:38:49 |
| Jules Lamur | (ie. sandbox-fallback = false) | 21:39:03 |
| raitobezarius | AFAIK the podman rootless thing has a seccomp policy that prevents all unshare calls with any relevant arg | 21:39:13 |
| raitobezarius | If you get rid of that and you have subuid delegation, you can run with sandbox | 21:39:30 |
| raitobezarius | Otherwise hexa gave you the 50% performance penalty solution by using syscall interception | 21:39:46 |
| Jules Lamur | yep you're right, running with eg podman run --cap-add=SYS_ADMIN --security-opt unmask=/proc/* --rm -it works | 21:39:53 |
