[Backport release-24.11] format and sort top-level/python-packages.nix

[katexochen]

manual backport of #391087

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Let's backport the CI job as well.

[katexochen]

@wolfgangwalther Do we add the git-blame-ignores on release, too?

[wolfgangwalther]

Do we add the git-blame-ignores on release, too?

I'm not sure what the convention here is. It's unlikely to cause conflicts, because those are always added in separate commits and never make sense to backport 1:1. So we could as well add them. But it would probably not give us much if that's not done for other commits like that, too.

@infinisil WDYT?

[wolfgangwalther]

In any case, we can merge now to avoid merge conflicts from creeping in - we can always add the commit hashes later, if we want to.