| 2 Feb 2026 |
 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 |
| Psentee | Yes, I don't want the entire dep tree to be able to call builtins.getEnv and bake it into derivations. I want to specify the entry point, and have everything underneath pure eval | 12:26:40 |
| K900 | That's currently achievable with restricted-eval and I hope to eventually make it less jank | 12:27:12 |
| raitobezarius | https://docs.lix.systems/manual/lix/2.90/command-ref/conf-file.html#conf-restrict-eval | 12:27:42 |
| Psentee | (Also, my understanding is that impure eval allows unpredictable results, AFAIR fetching without a hash was allowed?) | 12:27:45 |
| raitobezarius | eval-time fetching without pinning is possible, yes | 12:28:24 |
| Psentee | So I want to have a parameterized entry point, but fully predictable evaluation afterwards (no env access, no unpinned fetching, etc). I just want to easily inject parameters into the top level. Hopefully without templating an entire Nix expression as a string | 12:30:57 |
| Psentee | (Speaking of which, is ./${"/path/with/spaces and other \${funny characters"}"} the best way to write a path literal that will reliably escape anything that might occur in a path?) | 12:39:43 |
| K900 | Yeah that's something we want to eventually have a good way of doing in some capacity | 12:41:24 |
| Psentee | It's good there is a way, took me a while to figure out this trick;) | 12:42:16 |
| Psentee | Anyway, thanks for the help – looks like currently the best approach to get what I want is to stitch together a call expression. Not great, but I can live with that. Looking forward to that future CLI! | 12:46:44 |
| K900 | I personally want something pledge-shaped for eval at some point in the future | 12:48:46 |
| Psentee | (I'd offer to help if it only wasn't C++, Lix isn't exactly a beginner friendly project) | 12:49:03 |
| Psentee | * (I'd offer to help if it only wasn't C++, Lix isn't exactly a beginner friendly codebase) | 12:49:21 |
 0x4fbb09 it/its ⛯✇ΘΔ | pledge shaped in the cli or in nix code? | 12:50:16 |
| K900 | In Nix code | 12:50:27 |
