Right now, test_venv fails without distutils, because pip fails on importing the distutils module in pip/_internal/locations/_distutils.py

I reported this issue to pip: pypa/pip#11103

The distutils package was deprecated by the issue #85454.

PEP 632 "Deprecate distutils module": https://peps.python.org/pep-0632/

That seems like a good plan. Thanks.

My fear with renaming it is that it lingers indefinitely, and diverging in subtle ways from pypa/distutils. Why not address the dependencies and fully remove the functionality?

Regardless, I agree renaming is preferable to not removing the module at all.

Why not address the dependencies and fully remove the functionality?

Someone has to modify Python to no longer depend on distutils. The issue description lists code using it. It doesn't seem trivial.

Would it be reasonable to keep it around in the repo while we don't drop the dependency but not ship it as part of Python installations?

Would it be reasonable to keep it around in the repo while we don't drop the dependency but not ship it as part of Python installations?

With my PR, the Lib/_distutils/ directory is not installed by make install.

Do note that we have buildbots that run from an installed Python. The tests would need to also be modified to fail gracefully
(or skip) when _distutils is not available.

Do note that we have buildbots that run from an installed Python. The tests would need to also be modified to fail gracefully (or skip) when _distutils is not available.

I propose skipping tests relying on _distutils if _distutils is not available.

I wrote two PRs to avoid the deprecated distutils module in two tests:

• gh-92584: test_cppext uses setuptools #92639: test_cppext uses setuptools
• gh-92584: test_decimal uses shutil.which() #92640: test_decimal uses shutil.which() -- IMO an uncontroversial change

Hi @vstinner

I think #92639 is causing a test failure, details here #92820

PS: Commented here as I thought those changes are related to this PEP.

Marking as 3.12.0a1 release blocker. We want to have public-facing distutils gone in the first alpha, to have as much time as possible to deal with the fallout.

Actually we can get rid of distutils entirely. I have a working PR that gets rid of our setup.py and builds all extension modules with configure and make.

For the curious, the PR that @tiran is refering to is #94474

Marking as 3.12.0a1 release blocker. We want to have public-facing distutils gone in the first alpha, to have as much time as possible to deal with the fallout.

It seems that 3.12.0a1 was released with distutils. Was that intentional? cc. @Yhg1s

I was going to ping the issue during the core dev sprint and then intentionally ignore it for the alpha 1 release (using it more as a practice run rather than trying to get everything right) -- but then I accidentally ignored it instead 😬. This should just get done for alpha 2.

Not sure why this got put on me. If nobody else wants to do it, I can get to it eventually, but I definitely don't want to prevent anyone else from taking the honours.

Since May, the situation evolved:

• Python setup.py has been removed: distutils is no longer needed to build Python
• pip has been fixed: it now works if there is no distutils package
• test_cppext now creates a virtual environment to build the C++ with setuptools
• test_decimal now uses shutil.which(), rather than distutils.spawn.find_executable()

Thanks to that, I was able to create PR #99061. This PR removes the distutils package. It always skips test_check_c_globals and test_peg_generator since they use distutils. I prefer to remove distutils now, and fix these tests later, rather than missing the next Python 3.12 alpha release.