There are some failures with scipy on 32bit linux: https://github.com/scikit-learn/scikit-learn/runs/4600069041?check_suite_focus=true

Would we trigger the following error by not creating the manylinux1: #19233

The issue with distutils/setuptools/numpy should be solved there: numpy/numpy#20640

The issue in #19233 came from their configuration was not using pip. manylinux1 is reaching EOL in Jan 2022. The major issue with removing manylinux1 is older systems come default with a pip 9, which can only get manylinux.

The issue with distutils/setuptools/numpy should be solved there: numpy/numpy#20640

This will not fix everything because older version of NumPy will not get the fix.
If the fix is released before we release 1.0.2, then we can revert the setuptools pin.

I really like how SciPy's pyproject.toml places upper bounds in release branches. Their development branch has no upper bounds.

I think we need to pin setuptools anyways because of pip install scikit-learn will fail for source installs. (which does not have the env set.

manylinux1 is reaching EOL in Jan 2022

Yep let's drop it then. I think it would be cool to have a note in the release note that something can go sideways with easy_install then.

Are there any plans to support newer setuptools? A lot of other packages require setuptools 60+, making it difficult to build multiple packages from source.

@adamjstewart Yea, I think it's safe to raise the upper bound for setuptools, since we no longer depend on numpy.distutils. I opened #25651 to propose this change.