| 2 Feb 2026 |
 K900 | Autocalling was a mistake | 11:48:17 |
 piegames | In reply to @psentee:matrix.org
(is the answer "The nix CLI is as much of a mess as flakes are, and without flakes you should be using the old CLI"? I like the nix CLI, even without flakes, and so far I've avoided learning the old incantations, I hope to continue using nix, but I'll accept "this CLI is irreparable mess, don't expect any better" as an answer) It is an irreparable mess, however this specific mess is one that got inherited almost 1:1 form the old CLI | 11:52:12 |
 Psentee | Huh. Functors aside, is there any situation where a «lambda …» from nix eval/nix build/nix run would be useful? Trying to call it seems like a good attempt to arrive at something useful. Especially when there are explicit --arg / --argstr switches (I'd say if these switches are set it's no longer "auto"calling, it's requested by user) | 11:52:22 |
| piegames | Notably, autocalling only works for functions with an attrset destructuring | 11:52:39 |
| piegames | In reply to @psentee:matrix.org
Huh. Functors aside, is there any situation where a «lambda …» from nix eval/nix build/nix run would be useful? Trying to call it seems like a good attempt to arrive at something useful. Especially when there are explicit --arg / --argstr switches (I'd say if these switches are set it's no longer "auto"calling, it's requested by user) Yes, fpr denugging purposes | 11:53:16 |
| K900 | In reply to @piegames:flausch.social
Notably, autocalling only works for functions with an attrset destructuring In argument position | 11:53:59 |
| Psentee | IMO a reasonable consistent behaviour would be "if --file/--expr is a function, always call" (if function won't take the args we have, then it's an error). For debugging purposes, one switch could disable that. (Or the reverse: an explicit --arg/--argstr would enable calling – now it doesn't seem to change the behaviour at all, it's just a NOP half the time) | 11:56:30 |
| Psentee | I do have a use case for calling with --arg: I want to pass the currently running system to my machinery without having to write nix eval --expr "import $PATH { … }" instead of nix eval --argstr … … -f "$PATH"` (composing nix expression as a string is an escaping hell I'd prefer to avoid) | 12:00:05 |
| Psentee | Honest question: is the old style nix-* CLI better behaved / more consistent than nix? Should I abandon nix together with flakes? The nix CLI seems to at least attempt consistency (installables, build/eval/run being symmetrical and repl quite close to them) | 12:02:22 |
| K900 | No | 12:05:46 |
| 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 |
