[BUG] setuptools' distutils override no longer shows DeprecationWarning

[tiran]

setuptools version

setuptools==65.0.1

Python version

any

OS

any

Additional environment information

No response

Description

Recent versions of setuptools override Python stdlib's distutils with setuptools._distutils via _distutils_hack. This version does not contain code to issue deprecation warnings. It's a deviation from upstream code. setuptools should keep the deprecation warning to inform users that they should move from distutils to setuptools.

See also #3532

Expected behavior

$ venv/bin/pip install "setuptools==59.6.0"
$ venv/bin/python -Werror -c "import distutils"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.10/distutils/__init__.py", line 19, in <module>
    warnings.warn(_DEPRECATION_MESSAGE,
DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives

How to Reproduce

1. python3 -m venv venv
2. Install recent setuptools, e,g. venv/bin/pip install "setuptools==65.0.1"
3. Run venv/bin/python -Werror -c "import distutils"

Output

no output, command does not raise a deprecation warning

[jaraco]

That behavior is working as intended. The distutils module is deprecated in stdlib, but not in setuptools, which releases at a difference cadence and with broader compatibility across Python versions. I do intend to deprecate distutils now that it's stabilizing without platform-specifc monkeypatches, but it'll take some work to supplant or obviate all of the behaviors on which users currently rely on distutils.

Part of the challenge of deprecating distutils is that Setuptools still depends on it, so Setuptools will need to stop using it or suppress the deprecation warnings.

[n1ngu]

At first I was surprised not to see the deprecation warning when importing distutils but, I have been trying to wrap my head around it and AFAIU from #417 (comment) and the very PEP 632

As the distutils code is already included in setuptools, there is no need to republish it in any other form. Those who require access to the functionality should use setuptools or an alternative build backend.

distutils is expected to survive distributed alongside setuptools. Therefore, the target audience for the warning in the stdlib would only be those who fail to either make setuptools available or to bootstrap the _distutils_hack.ensure_local_distutils call.

In a near future, the stdlib distutils codebase will not cease to evolve but to very exist. Then, the copy that is now vendored here will be the de-facto upstream source, and its ownership will fall on setuptools' hands.

That said, because distutils is such a mess, everybody should be encouraged to replace any of its functionality with modern alternatives. Setuptools should tell what distutils functionality is a maintenance burden and is to be deprecated and trimmed in every release just like 1701579. In this regard, I think the ball is already on setuptools' roof. But the distutils core does not need to be deprecated unless setuptools wants it so! Namely, the parts that setuptools still relies on.

I think the actual challenges are

• How developers using distutils are made aware that their software should list an explicit dependency on setuptools and not rely on its ubiquity. Hopefully, someone will install that software in a pristine-empty virtualenv (python -m venv --without-pip ...) and notice the stdlib warning before before a broad adoption of Python-3.12?
• How setuptools will keep patching distutils in the timespan that it supports both Python<=3.11 and Python>=3.12. A post-python-3.11-EOL scenario (late 2026) is simpler: the _distutils_hack could be straightaway dropped and the now vendored distutils be packaged as a first-class citizen.

I hope I am not saying anything stupid. Please tell me so.

[n1ngu]

What @tiran observes is a direct consequence of b6fcbbd. Because setuptools>=60 do patch distutils by default, there is no need for you to see the deprecation warning. Distutils is being deprecated from the stdlib, not (yet) from setuptools.

[tiran]

Distutils is being deprecated from the stdlib, not (yet) from setuptools.

And that's IMO wrong. Since basically every Python distribution and virtual environment comes with setuptools pre-installed, almost nobody gets the deprecation warning. How should users learn that they should move off distutils? This behavior goes against intent of Python core and specification of PEP 632.

The change of behavior should have been discussed with us and documented in PEP 632. @zooba

[zooba]

I think this is fine. The distutils that comes with setuptools is not deprecated by PEP 632, but will be deprecated on its own schedule.

Hopefully the team will figure out a way to deprecate it feature-by-feature and retain enough compatibility for straightforward uses to keep working for as long as possible (I expect by moving implementation into setuptools and turning distutils into a wrapper with fine-grained deprecation warnings). The point was to save us from having to figure out how to do it in core without anywhere obvious to put the functionality.

So it's deprecated to use distutils from the standard library, and the easiest fix is simply to require setuptools to fix the warning. The fact that setuptools often comes with a standard CPython install just means that most users won't see one big deprecation warning breaking their builds, but over a much longer period of time will see the more obscure edges start showing warnings.