derivation to expose all the fields

[kvtb]

instantiated derivations expose .drvName and output as calculated fields:

nix/src/libexpr/primops.cc

Lines 1206 to 1227 in 099df07

	/* Write the resulting term into the Nix store directory. */
	auto drvPath = writeDerivation(*state.store, drv, state.repair);
	auto drvPathS = state.store->printStorePath(drvPath);
	printMsg(lvlChatty, "instantiated '%1%' -> '%2%'", drvName, drvPathS);
	/* Optimisation, but required in read-only mode! because in that
	case we don't actually write store derivations, so we can't
	read them later.
	However, we don't bother doing this for floating CA derivations because
	their "hash modulo" is indeterminate until built. */
	if (drv.type() != DerivationType::CAFloating) {
	auto h = hashDerivationModulo(*state.store, Derivation(drv), false);
	drvHashes.lock()->insert_or_assign(drvPath, h);
	}
	state.mkAttrs(v, 1 + drv.outputs.size());
	mkString(*state.allocAttr(v, state.sDrvPath), drvPathS, {"=" + drvPathS});
	for (auto & i : drv.outputs)
	mkOutputString(state, v, drvPath, drv, i);
	v.attrs->sort();

Is it possible to expose all the 7 fields of computed derivation, for example as

.final.outputs
.final.inputDrvs
.final.inputSrcs
.final.platform
.final.builder
.final.args
.final.env

?

.inputDrvs .inputSrcs are especially interested to have at eval time to deal with the dependency graph ( .drv-files are not always written to disk, so eval time is the only time when the graph exists) and to fix nixpkg's features like checkMetaRecursively, which rely on explicit dependencies mentioned in buildInputs, propagatedBuildInputs, ... and miss the deps brought via stdenv or as "${coreutils}/bin/xxx":

https://github.com/NixOS/nixpkgs/blob/40bb731ec71bdd7e85ae8c00208d90042e98ce21/pkgs/stdenv/generic/make-derivation.nix#L137-L138

[stale]

I marked this as stale due to inactivity. → More info

[roberth]

checkMetaRecursively

The solution you describe does not help with meta, because meta is never reported to derivation (or derivationStrict) as that info does not belong in a derivation, to avoid rebuilds and to permit more types (if you also consider "passthru").

Might #4677 help you with this?

Do you have another use case for the actual store level derivation info - ie all strings, no arbitrary values?