lib.systems: deprecate `==` comparison between elaborated platforms by MattSturgeon · Pull Request #380005 · NixOS/nixpkgs

MattSturgeon · 2025-02-07T06:04:22Z

As suggested by @wolfgangwalther #380005 (comment), I've scaled back this PR to focus on the treewide deprecation of == comparison between elaborated platform attrsets. The other changes are replaced by #380342.

This is in contrast to the previous effort to fully support == with elaborated platform attrsets: #238331. Also related: #278001.

A "backwards compatibility" item has been added to the release notes.

Added equals and notEquals functions to elaborated systems. This makes replacing == and != usage simpler, and also provides a convenient alternative to using lib.systems.equals directly.

Added an extra attr (warnAboutEquality) to elaborated systems that exists only to produce a warning when evaluated. This is intended to detect == comparison being used with platform attrsets, suggested by @roberth #380005 (comment).

This approach isn't perfect, because it is only evaluated if the == comparison has not already short-circuited. E.g. if the attr-count is different or some other difference has already been found before getting to the warnAboutEquality attr. These limitations were raised by @wolfgangwalther #380005 (comment) and were also discussed in this note.

The treewide change has been done using some regex search/replace together with vim's quickfix list and some manual checking. It covers ~600 changes, so I haven't been able to check each individual replacement in detail. As mentioned by @roberth, many of the replacements could probably use canExec instead of equals, but that change is not in scope for this PR.

Old summary

Intended to enable composition of package sets by preserving the original un-elaborated arguments passed to lib.systems.elaborate.

This PR does not actually make package sets composable, but it is intended that the implementation proposed here will enable @wolfgangwalther to revisit their earlier work in #303849 and #376988 without needing to make changes to the public API or the nixpkgs nixos module.

Adds:

lib.systems.isElaborated
A _type tag for elaborated systems
input attr on elaborated systems
lib.systems.equals ignores the new input attr

Additionally:

added equals and notEquals "method" attr-functions for convenience, and to allow comparison without needing access to lib
treewide migration from == -> <platform>.equals
elaborated platforms now warn when fully evaluated, in order to warn against using ==

cc @wolfgangwalther @roberth

Things done

Add a 👍 reaction to pull requests you find important.

roberth

My thoughts. I'm not the most knowledgeable person on the subject of these platform values, but I'd like to support you and @wolfgangwalther if possible.

lib/systems/default.nix

FliegendeWurst

Another merge conflict appeared. LGTM otherwise.

FliegendeWurst · 2025-04-18T12:53:51Z

doc/release-notes/rl-2505.section.md

Not sure why the example replacement is replacing equals with canExecute.

It's one possible replacement for some cases, because often enough the == check is just trying to prevent "real cross" scenarios, where you can't execute the binaries on your build system. So for a lot of cases, this could be a better replacement, but it might not always be correct.

I know of many packages where the build system just doesn't understand the distinction between build and host. For such cases an equality check makes sense.

wolfgangwalther · 2025-04-19T12:51:14Z

To move this PR forward, I'd like to focus on the one thing that should be discussed most:

This is in contrast to the previous effort to fully support == with elaborated platform attrsets: #238331. Also related: #278001.

Previously, the plan has been to get rid of all functions in elaborated platforms to eventually support == properly. This PR moves away from this approach.

Are there any objections to this?

If not, I think we should ship the deprecation with 25.05. I would not consider the deprecation itself a breaking change, so I don't think we are bound to the 23rd as a date. Please voice your concerns, if any, until next Friday, the 25th of April.

emilazy · 2025-04-19T13:04:01Z

Sorry for taking so long to get around to this.

My tl;dr take:

It’s unfortunate that Nix == behaves so incoherently for equality on objects‐with‐methods like this. The hack to cause a warning or error is cool, but short‐circuiting means it will never catch things reliably. That makes me inclined to approaches that separate out data and functions where possible, as sad a limitation as that is.
I also think it’s valuable to be able to serialize platform definitions to JSON, etc.
However, you’re the ones who have put a ton of work into cleaning this stuff up, and I don’t know if there’s any easy way to get the desired behaviour with my preferred approach, so I don’t want my cheap takes to override your hard work; this is just my 2¢.
In the long run, I quite strongly believe that we should separate out inputs to platform elaboration from outputs. Currently we have one monolithic structure that gets “mutated” with outputs, and some things you specify on input get ignored, some produce incoherent combinations, and so on. It seems to me that we need separate types and interfaces for things you can use to specify a platform to Nixpkgs and computed values Nixpkgs derives from a platform specification. There will be overlap, of course, but to me this lack of separation is the root cause of all the problems we’ve had around this. I believe addressing this would probably allow us to have a plain‐old‐data approach while being able to adjust platform configurations by modifying the inputs rather than the outputs.
Honestly I’m not sure how much actually comparing platforms for exact equality makes sense as an operation in general…

MattSturgeon · 2025-04-29T20:08:57Z

Sorry for taking so long to get around to this.

I don’t want my cheap takes to override your hard work; this is just my 2¢.

I for one value your input! ❤️

It’s unfortunate that Nix == behaves so incoherently for equality on objects‐with‐methods like this.

Agreed. It's also worth noting that == is not just an issue because of functions, but also because of wanting to do things like separate input and output attrs within the platform. Two platforms with the same outputs should be considered equal regardless of their inputs.

The hack to cause a warning or error is cool, but short‐circuiting means it will never catch things reliably.

Yes, it's sad that we can't find a reliable way to print a warning on == use, but I think it is good enough to catch most cases.

I also think it’s valuable to be able to serialize platform definitions to JSON, etc.

This would be possible with a lib.systems.toJSON function that uses the same removeUnwanted as equals does. Sad that you can't directly pass the platform to builtins.toJSON, but I don't see a way around this.

That makes me inclined to approaches that separate out data and functions where possible, as sad a limitation as that is.

In the long run, I quite strongly believe that we should separate out inputs to platform elaboration from outputs.

That would also require the same == deprecation, assuming inputs and outputs were both stored within the platform structure.

#380342 is attempting to do something similar by capturing inputs in the override function's scope.

Honestly I’m not sure how much actually comparing platforms for exact equality makes sense as an operation in general…

👍

Allows replacing `lib.systems.equals foo bar` with `foo.equals bar`. This is useful when `lib` isn't readily available, and is often less verbose.

In preparation for deprecating `==` usage on platform attrs.

`(elaborated platform) == "string"` will always be false. This was probably intended as `(elaborated platform).system == "string"`. That said, this should usually be replaced with checking the relevant boolean attributes, such as `isLinux` or `isDarwin`.

Added `warnAboutPlatformEquals` to elaborated platforms. This new attr prints a warning when evaluated. This is intended to detect `==` comparison being used with platform attrsets. This isn't perfect, because it is only evaluated if the `==` comparison has not already short-circuited. E.g. if the attr-count is different or some other difference has already been found before getting to the `warnAboutPlatformEquals` attr. Added a "backwards compatibility" item to the release notes. Co-authored-by: Robert Hensing <[email protected]>

A `removeAttrs` call was added by 4eca30d We may as well use it to simplify the test's implementation.

…form`

emilazy · 2025-05-16T13:10:28Z

That would also require the same == deprecation, assuming inputs and outputs were both stored within the platform structure.

(FWIW, explicitly not mixing them was my intention – it makes sense to me to separate inputs and computed values, because that is exactly what lets you compute new values from a modified input. However I realize that would be a considerably bigger change to disentangle all this stuff.)

wolfgangwalther · 2025-05-16T13:22:20Z

However I realize that would be a considerably bigger change to disentangle all this stuff.

It would. I'm still exploring the idea lately, thus I haven't acted here, yet.

github-actions bot added the 6.topic: lib The Nixpkgs function library label Feb 7, 2025

MattSturgeon requested review from alyssais, emilazy, philiptaron, roberth and wolfgangwalther February 7, 2025 06:05

nix-owners bot requested review from Artturin, Ericson2314, RossComputerGuy and reckenrode February 7, 2025 06:05

github-actions bot added 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Feb 7, 2025

MattSturgeon force-pushed the elaborate/inputs branch from 9207755 to 903c2b8 Compare February 7, 2025 06:14

nix-owners bot requested a review from infinisil February 7, 2025 06:15

MattSturgeon force-pushed the elaborate/inputs branch 2 times, most recently from c12ddc8 to e105d83 Compare February 7, 2025 06:18

roberth reviewed Feb 7, 2025

View reviewed changes

lib/systems/default.nix Outdated Show resolved Hide resolved

lib/systems/default.nix Outdated Show resolved Hide resolved

lib/systems/default.nix Outdated Show resolved Hide resolved

MattSturgeon force-pushed the elaborate/inputs branch from e105d83 to d005e0b Compare February 7, 2025 12:42

FliegendeWurst approved these changes Apr 18, 2025

View reviewed changes

wegank added the 12.approvals: 2 This PR was reviewed and approved by two persons. label Apr 18, 2025

MattSturgeon force-pushed the elaborate/inputs branch from 28e5cf4 to bc90e2e Compare April 29, 2025 20:15

ofborg bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Apr 29, 2025

github-actions bot added 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. and removed 10.rebuild-linux: 11-100 This PR causes between 11 and 100 packages to rebuild on Linux. labels Apr 29, 2025

This comment was marked as resolved.

Sign in to view

MattSturgeon force-pushed the elaborate/inputs branch from bc90e2e to 06b7740 Compare April 30, 2025 16:43

This comment was marked as outdated.

Sign in to view

MattSturgeon mentioned this pull request Apr 30, 2025

frigate: fix platform-based condition #403106

Merged

13 tasks

MattSturgeon and others added 6 commits May 1, 2025 00:00

lib.systems.elaborate: add equals and notEquals attrs

20dc31e

Allows replacing `lib.systems.equals foo bar` with `foo.equals bar`. This is useful when `lib` isn't readily available, and is often less verbose.

treewide: use <platform>.equals not ==

0c5d464

In preparation for deprecating `==` usage on platform attrs.

lib/tests/systems.nix: simplify test_equals_unequal using removeAttrs

d4b968f

A `removeAttrs` call was added by 4eca30d We may as well use it to simplify the test's implementation.

nixos/nixpkgs: deprecate == support for hostPlatform & `buildPlat…

c0509c5

…form`

MattSturgeon force-pushed the elaborate/inputs branch from 06b7740 to c0509c5 Compare April 30, 2025 23:03

MattSturgeon mentioned this pull request May 2, 2025

opencv: fix != "x86_64-darwin" check; also use lib.systems.equals #403629

Open

13 tasks

Aleksanaa mentioned this pull request May 16, 2025

taler-wallet-core: correct broken condition #407498

Closed

13 tasks

wegank added the 2.status: merge conflict This PR has merge conflicts with the target branch label May 17, 2025

MattSturgeon mentioned this pull request Jun 17, 2025

nixos/dovecot: 2.3.21.1 -> 2.4.0 #388463

Open

13 tasks

emilazy mentioned this pull request Jul 2, 2025

lib.systems.equals is inefficient #421579

Open

wolfgangwalther mentioned this pull request Jul 19, 2025

postgresqlPackages.postgis: fix cross-compilation #424800

Merged

13 tasks

eclairevoyant mentioned this pull request Oct 29, 2025

Build failure: pkgsCross.mingwW64.pkgsStatic.stdenv #281596

Open

nixpkgs-ci bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Nov 13, 2025

Uh oh!

Conversation

MattSturgeon commented Feb 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Things done

Uh oh!

roberth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

FliegendeWurst left a comment

Choose a reason for hiding this comment

Uh oh!

FliegendeWurst Apr 18, 2025

Choose a reason for hiding this comment

Uh oh!

wolfgangwalther Apr 19, 2025

Choose a reason for hiding this comment

Uh oh!

FliegendeWurst Apr 19, 2025

Choose a reason for hiding this comment

Uh oh!

wolfgangwalther commented Apr 19, 2025

Uh oh!

emilazy commented Apr 19, 2025

Uh oh!

MattSturgeon commented Apr 29, 2025

Uh oh!

This comment was marked as resolved.

This comment was marked as outdated.

emilazy commented May 16, 2025

Uh oh!

wolfgangwalther commented May 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

MattSturgeon commented Feb 7, 2025 •

edited

Loading