ValidPathInfo JSON format should use null not omit field

[Ericson2314]

Motivation

Context

Blocked on #9994, tests will fail until this

A little progress on #10311

Priorities and Process

Add 👍 to pull requests you find important.

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

[thufschmitt]

Discussed during the Nix maintainers meeting on 2024-02-26.
Idea approved, but :

• Should be mentioned in the release notes
• Should be reflected in the json guidelines policy

• @edolstra: Potentially breaking change, although probably not a big one

  • Also only happens in the new command-line

• @thufschmitt: Do we care about having these null fields?

  • @roberth: Have a slightly different semantics, potentially interesting to distinguish

• Idea approved

• Should be mentioned in the release notes

• Should be reflected in the json guidelines policy

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-02-28-nix-team-meeting-129/40499/1

[roberth]

Have only reviewed docs so far.

[roberth]

Thoughts: we should recommend that consumers ignore any fields they don't know.
I also like the GraphQL-like idea of specifying which attrs to expect, so that the consumer can safely use the whole value without anything unexpected occurring in it.
However, this seems less relevant (and unlikely to see much adoption) in the CLI; rather applies more to a fetchTree meta return attr (#8940 (comment)), where use of the whole object is actually relevant for reproducibility. Or as a solution for in-sandbox path info JSONs that isn't quite as capable as versioning, but does prevent over-fetching.

[fricklerhandwerk]

Nice!

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-06-03-nix-team-meeting-minutes-149/46582/1