I didn't see this mentioned explicitly, but I assume __meta is not passed to the builder?

It's not entirely obvious how derivation meta data would be used in practice, especially since derivers are kind of useless (e.g. cache.nixos.org paths do have a deriver, but you have no way to get to them, so you wouldn't be able to get to the metadata). Perhaps in conjunction with #11749, the metadata could be propagated into the provenance records of store paths (which are already JSON).

I didn't see this mentioned explicitly, but I assume __meta is not passed to the builder?

Correct, and this is now also covered by a functional test.

not entirely obvious how derivation meta data would be used in practice

You can instantiate your stuff and inspect the metadata.
If you don't have the expression sources for what you've deployed, you probably should(!), but if you don't provenance could connect that back, either by eval reproduction, by reference or by value.

• eval reproduction: provenance has a pinned flakeref, and you can instantiate that to acquire derivations
• by reference: maybe you actually do have derivations in a store
• by value: meta could be duplicated into the provenance structures, and it will benefit from the infrastructure that's set up around this:
  • having a reliable interface between Nix and the expression world (ie derivation { __meta })
    (meta attribute is not reliable because not the whole derivation closure occurs as packages that are seen by the CLI)
  • that interface getting used, pkgs: Add config.derivationMeta nixpkgs#466932

So this is a good step towards making #11749 more effective.

• Store path provenance tracking #11749 -> improvements for when expression sources are not immediately known
• Hash modulo meta #14686 -> access the metadata for whole closures

Marking as draft.
CA should operate on the stripped derivation too. We shouldn't need distinct traces for this, because meta is not part of the build process.

• Realisations use regular drv paths again #15322

Still fits the model.

                derivation resolution                            usages
       ┌─────────────────────────────────────┐  ┌────────────────────────────────────────────────────────────────────────┐  



                  ╔════════════╗
                  ║  drvAttrs  ║
                  ╚══════╤═════╝
                         ║
                         ║ instantiate
                         ▼  
              ╔════════════════════╗             ╔════════════════╗
              ║ drvPath derivation ╟┄┄┄┄┄┄┄┄┄┄┄┄▷║  ✨ SBOMs ✨   ║
              ╚══════════╤═════════╝ ⋱          ╚════════════════╝
                         ║              ⋱──(status quo)
                         ║ resolve meta    ⋱
                         ▼                    ↘  ╔════════════════╗   ┌────────────────┐
       ╔═════════════════════════════════════╗┄┄▷║ IA output hash ╟┄┄▷│ .narinfo query │
       ║                                     ║   ╚════════════════╝   └────────────────┘
       ║  derivation for IA substitution     ║
       ║            (and more)               ║   ╔════════════════╗   ┌──────────────────────────────────────────────────┐
       ╚═════════════════╤═══════════════════╝┄┄▷║ hash           ╟┄┄▷│ 💀 CA deep build trace query f.k.a. realisation  │
                         ║                       ╚════════════════╝   └──────────────────────────────────────────────────┘
                         ║ resolve inputs
                         ▼
       ╔═════════════════════════════════════╗   ╔════════════════╗   ┌────────────────────────────┐
       ║  derivation, fully resolved         ╟┄┄▷║ hash           ╟┄┄▷│ Shallow realisation query  │
       ╚═════════════════════════════════════╝   ╚════════════════╝   └────────────────────────────┘

could probably improve some labels, but there ya go

My view is that we can land it now (needs review but idea approved), but before it is stabilized, it should be rolled into a "v2 input addressing" feature, which will no longer involve hashDerivationModulo at all.