Unexpected behavior when distutils is invoked before Setuptools

TL;DR We are forced to use distutils because setuptools has broken symlink processing and this causes distutils.errors.DistutilsClassError: command class <class '__main__.SDistCommand'> must subclass Command.

It works with setuptools<48 and the changelog doesn’t document any breaking behaviors for this version.

Repro:

$ git clone https://github.com/ansible/ansible.git
$ cd ansible
$ pip install -U 'setuptools>=48'
$ python setup.py sdist

(tried under Python 3.8)

Ref: https://github.com/ansible/ansible/issues/70456

[jorisvandenbossche]

We also run into this warning in pandas, where we use distutils.version for version checking in the actual library (so not just in the packaging code).

[jaraco]

Great. Thanks for enacting that.

I’m wondering if there’s something that Setuptools should do here to help other projects with similar usages from encountering the same issue as we bring the adopted distutils back. For example, the project could:

1. Prior to re-enabling the adoption, warn when ‘distutils’ appears in sys.modules (except on PyPy, where that’s the status quo on startup).
2. When re-enabling the adoption, error with a helpful message when distutils is replaced (again exempting PyPy).

I think I’ll enact (1) now and give it some time to percolate over the weekend and maybe longer.

Do please consider filing something with Ansible to investigate a long-term solution for what Ansible will do when distutils is sunset and all that’s left is Setuptools (as that’s the plan).