release: drop x86_64-darwin from supported systems

[MattSturgeon]

Thanks to #493997 we can drop x86_64-darwin from master's "supported systems" without affecting stable branches. Among other things, this means ci/eval will not evaluate x86_64-darwin on unstable branches and x86_64-darwin won't be included in the comparison artifact.

I suppose that hydra explicitly provides its own supportedSystem list when importing release.nix, so I didn't "clean up" supportedDarwin added in 533eb98.

I assume this doesn't need its own release note, because it's an implementation detail of the x86_64-darwin deprecation/removal that is already publicly announced.

Usage

Grepping for release-supported-systems.json, the main usage is CI and the top-level release bootstrap:

nixpkgs/ci/eval/default.nix

Line 56 in e1c1b84

builtins.readFile ../../pkgs/top-level/release-supported-systems.json

nixpkgs/ci/eval/outpaths.nix

Line 14 in e1c1b84

builtins.readFile (path + "/pkgs/top-level/release-supported-systems.json")

nixpkgs/ci/eval/README.md

Line 13 in e1c1b84

Defaults to the [supported systems](../../pkgs/top-level/release-supported-systems.json) for the branch.

nixpkgs/ci/github-script/supportedSystems.js

Line 5 in e1c1b84

path: 'pkgs/top-level/release-supported-systems.json',

nixpkgs/pkgs/top-level/release.nix

Line 22 in e1c1b84

supportedSystems ? builtins.fromJSON (builtins.readFile ./release-supported-systems.json),

nixpkgs/pkgs/top-level/release-haskell.nix

Line 13 in e1c1b84

supportedSystems ? builtins.fromJSON (builtins.readFile ./release-supported-systems.json),

nixpkgs/pkgs/top-level/release-staging.nix

Line 15 in e1c1b84

supportedSystems ? builtins.fromJSON (builtins.readFile ./release-supported-systems.json),

cc @emilazy in case there are implications I've not considered.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[emilazy]

This was already done on staging-next. Doing it here will break Hydra in the interim. Not sure I understand the purpose.

[MattSturgeon]

This was already done on staging-next [...] Not sure I understand the purpose.

Same purpose as #493096; I just missed that it'd been done already.

I do remember following that PR at the time, I just couldn't find it when looking for it today...
I looked at master's revision of the file, without checking staging or staging-next's. My bad.

Doing it here will break Hydra in the interim.

I don't understand how it'd break hydra (but then, I barely understand hydra). Thanks for confirming either way.

[emilazy]

No worries :) For reference, the drop sequence was #493997 → #492160 → #493096 → #492189 → #535508, with more clean‐ups and minor fixes pending. The first four had to be split up as each one unblocked CI for the next. There’s still the issue of #535855 failing CI, but we can probably just bypass that, or otherwise cherry‐pick #493096 right before landing it.

The reason it’d break things to do this on master now is that Hydra uses the default supportedSystems that reads from this file, so the next nixpkgs-unstable bump would stop building for x86_64-darwin. That would result in uncached packages (and potential breakage from CI not catching eval issues) without the accompanying error message from #492189, which would be bad UX for users. Landing it all with a staging-next cycle that rebuilds the world means that we sync up all of CI no longer checking the platform + an error message for users + everything being uncached. (We could temporarily override supportedSystems in Hydra, as we did for the stdenv‐only staging jobset while waiting for the drop to land, but there doesn’t seem to be any point in this case.)

(We need an error before we stop caching packages, and can no longer easily cache packages with an error, but it’s not strictly required to line that up with a staging-next cycle; we could have done it on master as well. However, it felt natural to me to line the two up: one, because staging-next rebuilding the world is obviously a good time to start saving the work of building for the platform, whereas incremental channel updates between cycles are less expensive; and two, because if a user happened to try overriding the error and saw that most things still seemed to be cached and working, they might be in for a rude surprise once the next staging-next lands and they begin bootstrapping everything from scratch – which would then fail, because of the clean‐ups in #535508.

The latter is admittedly not a huge UX concern because we deliberately don’t advertise the override in the error message, but it felt cleaner overall to me to do it like this.)