[Nix#9866] Derivation JSON `env` does not adhere to the JSON guidelines #63

New issue

Open

opened 2024-03-16 06:44:43 +00:00 by lix-bot · 0 comments

lix-bot commented

2024-03-16 06:44:43 +00:00

Member

Upstream-Issue: NixOS/nix#9866

Describe the bug

NOTE: Changing how derivations works is rather invasive, so the question for the new-cli effort is whether we want to design this now to be forward compatible with these changes.

Essentially this is inherited from builtins.derivation and the ATerm-based format, but it is exposed on the command line.
This is some deep legacy, but nothing that can't be solved. Solving it is worthwhile because it improves the user experience, complying with the guidelines, and answers other questions such as #9846 without having to come up with something completely arbitrary and subject to change.

Steps To Reproduce

nix derivation show nixpkgs#hello

Observe that each derivation has fields
- args
- builder
- env
- inputDrvs
- inputSrcs
- name
- outputs
- system
These look well defined, but env is not. It may contain various attributes, such as preferLocalBuild, etc, which affect scheduling and have no business being in the process environment.
(They should not be part of the output fingerprint either; #9259)
Observe that the top level is a dictionary. (So the command can't summarize any results without violating the guidelines or switching formats. That may be acceptable.)

Expected behavior

Derivations do not rely on env for scheduling attributes and such, because those are Nix-specific fields, not dict entries.
Derivations have a section of non-hashed fields; putting these together as fields in a top-level object means that we can add non-output-hashed fields without breaking compatibility with earlier Nix versions.

nix-env --version output

Additional context

Priorities

Add 👍 to issues you find important.

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/9866 **Describe the bug** NOTE: Changing how derivations works is rather invasive, so the question for the new-cli effort is whether we want to design this now to be forward compatible with these changes. Essentially this is inherited from `builtins.derivation` and the ATerm-based format, but it is exposed on the command line. This is some deep legacy, but nothing that can't be solved. Solving it is worthwhile because it improves the user experience, complying with the guidelines, and answers other questions such as #9846 without having to come up with something completely arbitrary and subject to change. **Steps To Reproduce** `nix derivation show nixpkgs#hello` - Observe that each derivation has fields - `args` - `builder` - `env` - `inputDrvs` - `inputSrcs` - `name` - `outputs` - `system` These look well defined, but `env` is not. It may contain various attributes, such as `preferLocalBuild`, etc, which affect **scheduling** and have no business being in the process environment. (They should not be part of the output fingerprint either; #9259) - Observe that the top level is a dictionary. (So the command can't summarize any results without violating the guidelines or switching formats. That may be acceptable.) **Expected behavior** - Derivations do not rely on `env` for scheduling attributes and such, because those are Nix-specific _fields_, not dict entries. - Derivations have a section of non-hashed fields; putting these together as fields in a top-level object means that we can add non-output-hashed fields without breaking compatibility with earlier Nix versions. **`nix-env --version` output** **Additional context** **Priorities** Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).