| 2 Feb 2026 |
 K900 | Definitely not more consistent | 12:05:52 |
| K900 | It's inconsistent in ways that may be preferable | 12:06:02 |
| K900 | At best | 12:06:04 |
 Psentee | It also seems that the old CLI doesn't have equivalent of nix run or nix repl | 12:11:22 |
| K900 | It does not | 12:11:59 |
| Psentee | Yeah, I'm staying with nix then. I understand I shouldn't build my tools using the autocalling and it's more likely to be removed than improved in the future? | 12:14:19 |
| K900 | Yes | 12:16:03 |
| K900 | But also, the entire CLI will likely eventually be replaced with something more sane | 12:16:24 |
| Psentee | If I want to pass data from CLI to my nix code without dropping into impure eval – is composing a Nix expression as a string / temporary file my best bet then? | 12:16:34 |
| K900 | But that's a very not soon kind of thing | 12:16:43 |
| K900 | In reply to @psentee:matrix.org
If I want to pass data from CLI to my nix code without dropping into impure eval – is composing a Nix expression as a string / temporary file my best bet then? This is something we might have a better design for sooner than a full CLI rework though | 12:17:16 |
| K900 | Scoped pure eval is something that's been discussed quite a lot | 12:17:35 |
| Psentee | A better CLI would be great! But I still need my tools to work now. I'll probably be among the first ones to switch | 12:17:49 |
| K900 | The "canonical" way of providing external input to flakes is --override-input nonsense | 12:18:30 |
| Psentee | (And if a better CLI is somewhere on the roadmap, it explains why you wouldn't want to put too much effort into cleaning up nix) | 12:18:35 |
| K900 | Generally I'd say you probably just want to avoid doing that | 12:18:46 |
| Psentee | Yeah, I gave up flakes some time ago and I'm happier for that. Now I'm writing some tools on top of nix to remove some pain points / add some convenience in a non-flake workflow | 12:20:10 |
| K900 | Then you're not doing pure eval | 12:21:28 |
| K900 | Technically | 12:21:35 |
| Psentee | One feature of flakes I want to imitate is nix run flake#output injects system into the attribute path. I want this, but (1) more generalized (e.g. I'd want to read current system when loading npins to use its new nixpkgs-based fetching), (2) without having to enumerate all supported systems in my attrsets (which was a pain in flakes as well) | 12:22:36 |
 raitobezarius | builtins.currentSystem returns that with non-flakes | 12:24:09 |
| raitobezarius | (2) you can simply use a cross-compilation mechanism | 12:24:21 |
| Psentee | Why nix eval --expr 'import ./. { system="aarch64-linux"; }' is pure (which means nix eval --expr "import ./. { system="$(nix config show system)"; }"is also pure), butnix eval --expr 'import ./.' --argstr system "$(nix config show system)"` is not? | 12:25:09 |
| Psentee | this requires non-pure evaluation | 12:25:25 |
| K900 | Do you care about that? | 12:25:43 |
| Psentee | * Why nix eval --expr 'import ./. { system="aarch64-linux"; }' is pure (which means nix eval --expr "import ./. { system="$(nix config show system)"; }"is also pure), butnix eval --expr 'import ./.' --argstr system "$(nix config show system)"\ is not? | 12:25:43 |
| K900 | There's no practical difference | 12:25:49 |
| raitobezarius | If you are using pure evaluation to prevent a set of exprs to access non-locked inputs or something, restricted-eval is a thing | 12:26:08 |
| raitobezarius | and you can control things with allowed-uris | 12:26:13 |
| K900 | In most cases | 12:26:18 |
