| 13 Mar 2025 |
 puck | In reply to @mschwaig:matrix.org
I'm trying to re-implement the way content-addressed derivations do dependency resolution from unresolved to resolved (aka basic) derivation, but outside of Nix - because I'm trying to do stricter validation with different signatures. I've gotten fairly far with that, but I'm seeing some "placeholder paths" like "/163l1qfs4mlpsl1g8m4ra6n08n8cscdgs9xgcbpijp61c1fjhcal" or "/0k24dfvijqra5pjhd1xhkg467fvh33cllgsxvpyklyhzymrm13xb/bin/bash" in the output of nix derivation show in places like the builder field of unresolved derivations. I don't know how I can resolve those myself, because I don't know how to find out either the unresolved derivation output it is associated with, or the store path nix wants it resolved to. In contrast, I can already resolve the outputs listed in inputDrvs to store paths myself just fine with the same results as Nix.
So I'm wondering, how do those placeholder paths work?
I saw that builtins.placeholder exists, but I don't really get how that relates to my problem from just reading the docs. 😅
(I also see one such path in resolved derivations, but there it's always the same "/1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9" path in the "out" environment variable, so I think that's a different issue.)
they are values derived from either the current drv's output, or any input drv + its output. its representation is / then the nixbase32 repr of the full sha256 of either "nix-output: " or "nix-upstream-output: :<the name the output would have; so either drv's name or append a dash and the output name>" | 16:39:23 |
| puck | you'll have to pessimistically calculate every possible placeholder and its replacement value, then just search+replace the environment and builder args for said placeholders | 16:40:00 |
| puck | (note though, you may want to check the signature that gets signed for realisations if you haven't already; it might serve your needs if you just want a drv + its realised input paths signed) | 16:41:04 |
| puck | In reply to @puck:puck.moe
they are values derived from either the current drv's output, or any input drv + its output. its representation is / then the nixbase32 repr of the full sha256 of either "nix-output: " or "nix-upstream-output: :<the name the output would have; so either drv's name or append a dash and the output name>" uh, one colon. element's not letting me edit this message :v | 16:42:22 |
 jade_ | NIX_REMOTE | 20:41:29 |
| jade_ | its really badly documented but it is actually equivalent to --store internally; see my hastily scrawled notes on all env-vars used by cppnix derivatives https://docs.lix.systems/manual/lix/stable/contributing/testing.html?highlight=NIX_REMOTE#used-by-lix | 20:42:58 |
 John Ericson | You can also use just use NIX_CONFIG, the one env var to rule them all | 20:48:09 |
| jade_ | mhm | 20:49:55 |
| jade_ | it seems like sometimes env-vars get introduced like NIX_ABORT_ON_WARN which should just be more NIX_CONFIG | 20:51:35 |
| John Ericson | If they correspond to an option, yes | 20:55:44 |
| John Ericson | Btw, you should see what we just did to derivation goal | 20:55:58 |
| John Ericson | Even if you're gonna rewrite it in Rust anyways | 20:56:06 |
| 14 Mar 2025 |
| jade_ | yeah, NIX_ABORT_ON_WARN does, i am not sure why it was added; we caught this in code review of builtins.warn | 00:04:27 |
| John Ericson | No idea either | 04:20:24 |
 Robert Hensing (roberth) | Continuity with Nixpkgs lib.warn, and in turn the ability to produce a trace from the first warning encountered | 08:20:46 |
| Robert Hensing (roberth) | Could be deprecated I think | 08:22:02 |
 emily | the functionality is used by e.g. Nixpkgs release checks but I think the question is why it's an environment variable | 15:27:32 |
 magic_rb | Sounds like it should be a cli flag | 15:42:31 |
| jade_ | aaaaaaah this explains a lot as well as why it is not a CLI flag. okay. admissible I guesssssss, but bad.
IMO we should fix the release checks to set the nix config instead. | 16:44:20 |
| jade_ | * aaaaaaah this explains a lot as well as why it is not a CLI flag. okay. admissible I guesssssss, but bad.
IMO we should fix the release checks to set the nix config as well | 16:44:32 |
| emily | I mean it's nix-instantiate or whatever inside a Nix derivation | 16:46:19 |
| emily | so it could very much just use a flag instead | 16:46:22 |
