MAINT: be more tolerant of setuptools>=60#20963
Conversation
NumPy may fail to build with the default vendored distutils in setuptools>=60. Rather than panic and die when new setuptools is found, let's check (or set, if possible) the SETUPTOOLS_USE_DISTUTILS environment variable that restores "proper" setuptools behavior.
|
I am worried that setuptools will remove the |
|
Even if SETUPTOOLS_USE_DISTUTILS goes away, it weakens the constraints on setuptools and we can always add a hard limit later on if necessary. Maybe a simple and sufficient test is to import I would still like to know what build failures occur the vendors distutils, because I have not seen any problem building on Void with setuptools-60.5.0 whether or not I try to disable the vendored distutils. |
|
The point of the check was to reduce reported issues due to using the wrong setuptools version. If this helps, lets give it a try until things break again. |
|
Thanks @ahesford . |
NumPy may fail to build with the default vendored distutils in setuptools>=60. Rather than panic and die when new setuptools is found, let's check (or set, if possible) the
SETUPTOOLS_USE_DISTUTILSenvironment variable that restores "proper" setuptools behavior.We were bitten by #20759 and #20795 in Void Linux, which has already moved to setuptools>60.
Note that I cannot reproduce a build failure (at least not on maintenance/v.1.22.x) even when the new default isn't overridden. (That is, reverting #20759/#20795 is sufficient to allow NumPy to build for me.) However, in certain cases where it the new default might cause problems, this change should thread the needle. Sticking with setuptools < 60 for the next year while NumPy moves to a new build system is simply not a good option for Linux packagers.