| 30 Nov 2025 |
 @acidbong:envs.net | understandable, i guess i'll abstain from it (lib.pipe is already familiar for me) | 18:44:11 |
 raitobezarius | In reply to @weethet:catgirl.cloud
Also I thought that both flakes and nix3 CLI were gonna be moved to a separate module? Not nix3 CLI | 18:47:01 |
| raitobezarius | Flakes yes | 18:47:04 |
| raitobezarius | It's going to be very very progressive | 18:47:12 |
| raitobezarius | (and yes this means that plugins will gain the ability to extend the REPL) | 18:49:52 |
| raitobezarius | (or the nix3 CLI itself) | 18:50:03 |
 WeetHet | How would nix3 cli function without flakes? | 18:53:41 |
 niklaskorz | if you specify a file with -f it works on normal nix files instead of flakes | 19:02:06 |
| WeetHet | Yeah but nix3 cli with -f is just strictly worse than nix2 cli? | 19:02:34 |
| niklaskorz | well that wasn't your question | 19:03:14 |
| niklaskorz | I too prefer nix-build when working with normal files :D | 19:03:49 |
| WeetHet | What's the point in leaving nix3 CLI in Lix if it would be there strictly so that an external plugin would work | 19:04:00 |
| niklaskorz | (or nom-build, for that matter) | 19:04:04 |
| niklaskorz | there are some more or less agreed upon improvements to be made I think, like defaulting to default.nix if no flake.nix is found (or if no flake plugin is enabled I suppose) | 19:05:11 |
| niklaskorz | and then interpreting the list of installables as attributes, so nix build foobar would be equivalent to nix-build -A foobar | 19:06:05 |
| WeetHet | What is the advantage to doing that instead of just working with nix2 cli? | 19:06:36 |
| WeetHet | * What is the advantage in doing that instead of just working with nix2 cli? | 19:07:27 |
 just1602 | Having a unified CLI? | 19:12:16 |
| WeetHet | By unified CLI do you understand nix smth instead of nix-smth? If yes, just creating aliases would work | 19:13:28 |
| 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 |
