| 30 Nov 2025 |
 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 |
| raitobezarius | In reply to @jlamur:matrix.org
yep you're right, running with eg podman run --cap-add=SYS_ADMIN --security-opt unmask=/proc/* --rm -it works I think you can get remove just the unshare blacklist | 21:40:13 |
| raitobezarius | Don't need to unmask proc and cap add | 21:40:20 |
| raitobezarius | For proc, you only need a partial view, not a full view anyway, but you need a proper procfs I suppose | 21:41:03 |
