In reply to @roberthensing:matrix.org
What do we think of suffixing fields with _ to make them visually distinct from locals/params? I'm open to it (implicit this-> may have been a mistake, hurting understanding and refactoring) but esp John Ericson tomberek Eelco Mic92 will also have to look at such code

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.)

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.)

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>"