Store `StructuredAttrs` directly in `Derivation`

[Ericson2314]

Instead of parsing a structured attrs at some later point, we parsed it right away when parsing the A-Term format, and likewise serialize it to __json = <JSON dump> when serializing a derivation to A-Term.

The JSON format can directly contain the JSON structured attrs without so encoding it, so we just do that.

Motivation

~~Depends on #13273~~ ~~Depends on #13349~~

Context

---

Add :+1: to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[Ericson2314]

Thanks to talking to @puckipedia, I became satisfied that the other way of changing the abstract syntax (pair of env and optional structured attrs) wasn't "too lax" because there already was a way within the language to mix arbitrary env vars with structured attrs.

This PR is now updated to work that way, and is passing all the tests, but let's look at #13273 first.

[dpulls[bot]]

:tada: All dependencies have been resolved !

[Ericson2314]

Notes from today's Nix team meeting:

• What about perf of parsing the structured attrs eagerly?

  • @mic92 can check, perhaps

• What about derivations that no longer parse during GC?

  This branch in https://github.com/NixOS/nix/blob/20226c85bcb141b02dcf87dd8fcf16df0dc85a2b/src/libstore/gc.cc#L754-L760 does parse derivations, to see if they point to outputs we should keep.

  We should recover if we fail to parse a derivation, and have a test for this. We also need to decide what we want to do in that case: delete or keep the derivation that doesn't parse?

• @edolstra what are the use-cases / ultimate purpose you have for doing this?

  @ericson2314: Sure

  • Better derivation JSON format (or other new formats):

    That is useful for #8602 and dynamic derivations

  • Maybe better on-disk format too

    For input-addressed outputs, ATerm has to stick around forever at least as part of the path calculation. But for the newer experimental derivations types we have the opportunity to do a clean break.

[tomberek]

Needs discussion to address potential perf and laziness implications.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2025-05-28-nix-team-meeting-minutes-229/65205/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2025-05-04-nix-team-meeting-minutes-230/65206/1

[dpulls[bot]]

:tada: All dependencies have been resolved !

[Ericson2314]

I turns out the reading derivation issue we were worried out just occurs with CA derivations #13575. Furthermore, an existing plan quite orthogonal to this PR solves the problem --- no more reading derivations in that case, just like in the input-addressing and fixed-output CA cases.

Therefore, I think this PR is unblocked: it poses no perf or GC behavior issues with the presence of stable features.

[roberth]

Discussed in meeting today: @Ericson2314: previous concerns have been addressed. @Ericson2314: this does canonicalize __json on read. A drv file would have to be crafted to observe this new behavior. It can't be created through the language since https://github.com/NixOS/nix/pull/13273 @Mic92: approved

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2025-07-30-nix-team-meeting-minutes-238/67400/1