python312Packages.distutils: init at 0.70.0

[dotlambda]

Description of changes

fixes #328346
fixes #326296
closes #326321
fixes #326920

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[emilazy]

Would this same issue also be solved by fixing the issue that causes setuptools to not provide distutils for us? I would personally feel more comfortable with that as an interim solution than depending on another random third party. There’s no commit history in this repository either, and the distutils licence mentioning nntplib doesn’t fill me with confidence.

[kfollesdal]

I would be more comfortable to use a more official source https://github.com/pypa/distutils, that is the source for the distutils that setuptools offer.

[dotlambda]

Would this same issue also be solved by fixing the issue that causes setuptools to not provide distutils for us?

Yes.

I would personally feel more comfortable with that as an interim solution than depending on another random third party.

Same. But that's a mass rebuild.

[emilazy]

What if we add a distutils package that just re‐exports the version from our setuptools package at the right path? That avoids a mass rebuild and offers a simple path towards migrating it back into setuptools package during a staging cycle (but it might actually be valuable for us to know what is using distutils, since ideally nothing should be).

[dotlambda]

What if we add a distutils package that just re‐exports the version from our setuptools package at the right path?

It seemed easier to use https://github.com/pypa/distutils because it comes with pyproject.toml. So that's what I did.

[kfollesdal]

I have made a proposal to fix setuptools support for distutils so it behaves as expected. I prefer to fix setuptools rather than introducing an extra package. #328415

[dotlambda]

I'm now pulling the code, except for tests, build files, etc., from our setuptools package. So compatibility should be guaranteed.

[dotlambda]

I'll merge this now cause the other option needs a whole staging cycle. If we agree the other solution is better we can revert this on staging.