| 2 Feb 2026 |
 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 |
| K900 | restrict-eval is kinda that for CLI already | 12:50:35 |
 llakala | 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? --expr is what I choose when I need to test something, since I can have faith that it'll actually work | 13:51:59 |
|  holly [nexus] 🏳️⚧️ changed their display name from holly to holly [nexus]. | 13:52:01 |
| holly [nexus] 🏳️⚧️ changed their display name from holly [nexus] to holly [nexus] 🏳️⚧️. | 13:52:30 |
 WeetHet | https://tangled.org/weethet.bsky.social/nix-run | 16:47:37 |
| llakala | In reply to @weethet:catgirl.cloud
https://tangled.org/weethet.bsky.social/nix-run yay someone already made this, I don't have to | 18:09:31 |
| llakala | * yay someone already made this, now i don't have to | 18:09:47 |
| WeetHet | https://github.com/NixOS/nixpkgs/pull/464655
I with someone with commit access merged this | 18:16:49 |
 QuadRadical (Ping) | someone indeed di | 19:36:14 |
| QuadRadical (Ping) | * someone indeed did | 19:36:17 |
| WeetHet | Thanks raitobezarius | 19:37:13 |
| WeetHet | I really appreciate that | 19:37:21 |
| raitobezarius | np | 19:37:28 |
| QuadRadical (Ping) changed their display name from QuadRadical (Ping) @ FOSDEM to QuadRadical (Ping). | 20:27:28 |
 Jules Lamur | Is there work on having a native/well integrated and secure way of passing credentials to the sandbox?
Is that something you think would be nice to have in the Nix ecosystem?
For example, and to cite my use-case, being able to sign UKIs / Lanzaboote binaries without having keys on my target host or leave the sandbox.
Passing credentials via sandbox-paths is one way to achieve that but it's not safe IIUC as it will make the keys available to every other builds (and it's not a very nice UX for end-users.) | 20:38:10 |
