Let's make this a pleasant format and not propagate the pname tech debt. It only exists because we haven't found the courage to fix the problem of these redundant three variables.
For context, the way this works is that store path name == "${pname}-${version}" if the latter both are provided to mkDerivation.
pkg.name got the value of the store path name arguably by mistake.
The store path name part's purpose is for humans to read. It exists at the store layer and did not need to be passed back up to the Nix language layer. (More generally, I find that tacking the argument onto the returned derivation attributes is one of the biggest flaws of the language)
Instead, what Nixpkgs should do is claim the name name for itself, for its own purposes in packaging as opposed to a technical term from its underlying build system.

Having null values is good here. It shows that the omission of a value is not accidental or because of some change in the interface.

name, pname and version can be removed from preserveMetaFields.

Adding mainProgram to any other output than bin or out would be misleading, because no such program exists there.

We probably also have the opposite granularity problem, where one meta.json isn't sufficient for describing large store paths, for example a link farm, or (worse) a store path with combined content that's not linked but copied.

It might be wrong to write this to any outputs at all.
These things are quite subtle and by doing this we're not just creating worse data quality, but setting our users up for failure, because outputs by their very nature do not take into account all the build inputs, whose licenses and vulnerabilities will affect the output anyway. The closure of outputs is incomplete, so any analysis done using it will also be incomplete.

To illustrate, a static library dependency becomes part of the output (bytes, vulns, licenses), but it does not leave behind a reference to the original library and its meta.json.

In other words, tools should take into account the derivation closure, not just the output's closure. By storing the meta info in the derivation closure, we provide it faithfully in its original shape, and we set up our users to consider how to deal with these characteristics, instead of nudging them down the wrong path.

@roberth There's certainly a lot of truth to your analysis. I still think there may be additional value in keeping the meta in the outputs as well - even if it's only ~95% accurate. Even using derivations, do all language ecosystems (rust, go, npm, etc.) have a single derivation per-dependency? If not, we would encounter the same issue.

In any case, updating bonbom/sbomnix to take advantage of the derivation directly will take some time anyway and is probably sufficient for my uses. I'll move the nix-support/meta.json stdenv hook into it separate PR.

In other words, tools should take into account the derivation closure, not just the output's closure. By storing the meta info in the derivation closure, we provide it faithfully in its original shape, and we set up our users to consider how to deal with these characteristics, instead of nudging them down the wrong path.

I don't understand the exclusive OR here. This PR stores the info both in the derivation (all derivation arguments are exposed in the .drv after all) as well as in the output. It give you both.

I think having meta information of your runtime dependencies can still be useful. e.g. for a runtime threat scanner to be able to tell you if you're running a vulnerable version of something. Or for a container scanner that scans a nix-built container to match store paths to package databases. Then afterwards people can always reach for the derivation-level to get the whole accurate build-time view.

Even using derivations, do all language ecosystems (rust, go, npm, etc.) have a single derivation per-dependency? If not, we would encounter the same issue.

buildGoModule and friends should be responsible for customizing the meta hook to output their SBOM information in nix-support/. Go actually already stores dependency information of what it was built with inside the binary. So the meta information is already available.

% nix shell nixpkgs#go nixpkgs#caddy
% go version -m $(which caddy)
/nix/store/k369dl06sznpappxj4wr5fmh84x0zpjf-caddy-2.10.0/bin/caddy: go1.24.4
	path	github.com/caddyserver/caddy/v2/cmd/caddy
	mod	github.com/caddyserver/caddy/v2	(devel)	
	dep	cel.dev/expr	v0.19.1	
	dep	dario.cat/mergo	v1.0.1	
	dep	filippo.io/edwards25519	v1.1.0	
	dep	github.com/BurntSushi/toml	v1.4.0	
	dep	github.com/KimMachineGun/automemlimit	v0.7.1	
	dep	github.com/Masterminds/goutils	v1.1.1	
(...)
	build	-buildmode=exe
	build	-compiler=gc
	build	-tags=nobadger,nomysql,nopgx
	build	-trimpath=true
	build	CGO_ENABLED=1
	build	GOARCH=arm64
	build	GOOS=darwin

Bombon also has some code that does something similar for rust: https://github.com/nikstur/bombon/blame/main/nix/passthru-vendored.nix

The same we would have to do for statically linked binaries. Ideally the output of the statically built derivation contains meta information on what dependencies ended up being linked into the static binary (though modulo the nix store path. as we don't want references in static outputs I guess?). Similar to how we find propagated build inputs recursively for all our build inputs in setup.sh's findInputs, we can also collect meta info recursively of all out build inputs and then write the union of that as a build output. This might over-approximate as maybe not all buildInputs are used for linking in the end. But if we want exact info then this needs collaboration with the build tools of said packages to produce these info instead. See e.g. https://ariadne.space/2025/02/08/c-sboms-and-how-pkgconf.html

e.g. something like this (took the code from the pkg-config hook and adjusted.)

The trick is that the addToMetaPath hook gets called for all (propagated) inputs of the derivation. So it shows all our build time dependencies.

# Skip setup hook if we're neither a build-time dep, nor, temporarily, doing a
# native compile.
#
# TODO(@Ericson2314): No native exception
[[ -z ${strictDeps-} ]] || (( "$hostOffset" < 0 )) || return 0

addToMetaPath() {
    # See ../setup-hooks/role.bash
    local role_post
    getHostRoleEnvHook

    addToSearchPath "META_DEPENDENCIES${role_post}" "$1/nix-support/meta.json"
}

# See ../setup-hooks/role.bash
getTargetRole
getTargetRoleWrapper

addEnvHooks "$targetOffset" addToMetaPath

# No local scope in sourced file
unset -v role_post


writeMetaJson() {
  mkdir -p "$output/nix-support"

  # TODO: idk what the role_post stuff is needed here because not familiar with cross compile
  IFS=':' read -ra dependencies <<< "$META_DEPENDENCIES"

  # add a dependencies key containing the recursive meta json contents of all dependencies
  # code currently assumes `meta.json` always exists
  { echo "$nixMetaJSON" ; jq '{dependencies:.}' --slurp "${dependencies[@]}" } | jq --slurp . > "$output/nix-support/meta.json"


}

fixupOutputHooks+=(writeMetaJson)

buildGoModule and friends could have their own setup hooks that add their own specific meta json with information we don't get at the derivation level and have those merged as well.

I think having meta information of your runtime dependencies can still be useful. e.g. for a runtime threat scanner to be able to tell you if you're running a vulnerable version of something.

I'm not debating the usefulness of runtime dependency info, but we don't have that.
Runtime dependencies and an output's store path references are different concepts. (in a similar way that hermeticity and reproducibility should not be confused)

It surely doesn't help that some of us occasionally use "runtime dependency" for "dependency of an output" and we need to stop doing that. If we're talking about analyses, doubly so.

And herein lies the problem: how do you make sure that the runtime dependencies are even accounted for?
Static linking, header-only C/C++ deps, minified deps, or really any sort of bundled dependencies are invisible to the output's Nix reference graph. Unfortunately for this use case, that is actually a good thing. We don't want unnecessary store paths to be required at runtime.
The usual solution for this problem is to use a different output, but that immediately defeats the apparent goal of having a report readily available without using any Nix commands.

A built output with metadata may well serve a purpose, but any analysis that isn't derivation-aware is bound to have serious problems, so a built metadata thing in an output should only be considered in the context of a derivation-aware analysis.

Another use case for this output metadata is license checking. This system, for example, would allow one to much more easily check if their deployed system has any GPL components.

Of course, static linking/header only libraries are still an issue, but it's much easier to start from here and add a few items manually than starting from the entire derivation closure and removing all transitive build-time dependencies.