Maybe one more?

diff --git a/numpy/tests/test_public_api.py b/numpy/tests/test_public_api.py
index a9d6da01c..631eb836a 100644
--- a/numpy/tests/test_public_api.py
+++ b/numpy/tests/test_public_api.py
@@ -14,6 +14,9 @@ try:
 except ImportError:
     ctypes = None
 
+# from setuptools v49.2.0, setuptools warns if distutils is imported first,
+# so pre-emptively import setuptools
+import setuptools
 
 def check_dir(module, module_name=None):
     """Returns a mapping of all objects with the wrong __module__ attribute."""

Maybe one more?

Getting late for me. I'm thinking the real problem is in xdist since this doesn't happen without it.

Close/reopen after gh-16857

I took the liberty of pushing another fix

The point of this warning is that setuptools now vendors its own distutils package, so by importing setuptools it injects setuptools.distutils in sys.modules as if it is the stdlib distutils. So on the one hand we could pin our CI to use setuptools<49.2.0, but then one of the downstream projects might update setuptools and start getting warnings that actually come from numpy.

Another choice would be to require setuptools>=49.2.0, and refactor our code to import setuptools.distutils everywhere we import distutils.

setuptools now vendors its own distutils package

That seems... dangerous. There is probably a good reason for it, but replacing the standard library is darn fragile because of all the issues we are seeing.

So the best course of action for now might be to pin setuptools<49.2.0. I guess we can merge what we have here as a best-effort, or maybe revert some of the more invasive ones?

The point of this warning is that setuptools now vendors its own distutils package, so by importing setuptools it injects setuptools.distutils in sys.modules as if it is the stdlib distutils. So on the one hand we could pin our CI to use setuptools<49.2.0, but then one of the downstream projects might update setuptools and start getting warnings that actually come from numpy.

I think the best thing to do would be to pin setuptools != 49.2.0 here rather than setuptools < 49.2.0. I don't expect this to be an issue in the next release. We can give you a head's up if that changes before the next release.

Another choice would be to require setuptools>=49.2.0, and refactor our code to import setuptools.distutils everywhere we import distutils.

This is not quite right, because setuptools is not exposing its version of distutils as setuptools.distutils (and to the extent that it exists under the setuptools namespace, that location is not necessarily stable). setuptools replaces the top-level distutils module with its own version of distutils, so import distutils pulls the version from setuptools.

This is one phase of an ongoing project to remove distutils from the standard library (and probably eventually retire the project entirely in favor of setuptools).

I guess we can merge what we have here as a best-effort, or maybe revert some of the more invasive ones?

I rather avoid making a mess working around this, especially if it get fixed in the long run. I'd be more in favor of pinning the version and removing the workarounds we have already added. Things work now, so we can wait until upstream shakes out.

The best procedure is probably to pin first, then maybe revert the workarounds.

The setuptools version has been pinned.