top-level: add warning for x86_64-darwin deprecation

[emilazy]

We’ve never deprecated a platform in widespread use before, and it seems prudent to warn users about the upcoming end of support so they can plan appropriately.

I tried to make this relatively unobtrusive by taking advantage of the import cache and offering a way to turn it off, but I anticipate there might still be issues with e.g. nix shell nixpkgs#… and spammy warnings from multiple instantiations of Nixpkgs. I’m not sure there’s much we can do about that unless we take a different strategy entirely; nix shell --impure nixpkgs#… with a ~/.config/nixpkgs/config.nix is about the best UX we can hope to offer with the restrictions of flakes.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • 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.

[jopejoe1]

This would need some adjustments for GitHub CI in at least the following locations (maybe missing some)

https://github.com/NixOS/nixpkgs/blob/09ac1a4dd614f93d8588def74847f810cc9b329c/ci/eval/outpaths.nix#L28
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/packages-config.nix
https://github.com/NixOS/nixpkgs/blob/09ac1a4dd614f93d8588def74847f810cc9b329c/pkgs/top-level/release.nix#L39

[emilazy]

I already adjusted ci/eval/outpaths.nix (and the release checks). Hydra already gets tons of warnings every eval and is fine, so I backed out changes to release.nix that I had locally, and it doesn’t look like the packages-config.nix consumers should be broken by a warning. But unfortunately there are things in Nixpkgs that like to re‐import Nixpkgs, so I expect to have to do a little digging before CI passes, yeah.

[jopejoe1]

I already adjusted ci/eval/outpaths.nix (and the release checks).

My bad

Hydra already gets tons of warnings every eval and is fine, so I backed out changes to release.nix that I had locally, and it doesn’t look like the packages-config.nix consumers should be broken by a warning.

Ahh, yeah the CI jobs that made use of those where for x86_64-linux only

But unfortunately there are things in Nixpkgs that like to re‐import Nixpkgs, so I expect to have to do a little digging before CI passes, yeah.

We should really reduce the amount we re-import nixpkgs

[emilazy]

Spun off #492147, #492148, and #492152, which are blockers for this.

[emilazy]

@NixOS/nixpkgs-ci I understand that all changes to the ci directory should generally be backported, but I’m unclear on how we’ll want to handle this, #492160, and #492189, as the changes are definitely non‐backportable (the added Nixpkgs config won’t be supported on 25.11 – although I suppose we could backport that harmlessly – and we certainly won’t be able to backport the drop of the platform to 26.05). Thoughts?

[MattSturgeon]

@NixOS/nixpkgs-ci I understand that all changes to the ci directory should generally be backported, but I’m unclear on how we’ll want to handle this

Yes, we definitely want to keep the ci tree in-sync across supported branches. Where possible, we also want CI to run the same on all branches. But where that doesn't make sense, I suppose we could use version predicates?

Comments on the relevant CI code below.

[reckenrode]

LGTM.

[emilazy]

Okay, let’s see how this plays. Hopefully it doesn’t blow things up too much.