Closed Saransh-cpp closed 2 years ago
Upper-capping setuptools<=64.0.0
works for me locally! 65.0.0
gives the error mentioned above and in the CI pipeline.
But, NumPy
recommends hard pinning setuptools==59.2.0
.
Maintainers' call!
For more information -
PR that caused the breakage - https://github.com/pypa/setuptools/pull/3505 Issue that explains the breakage - https://github.com/pypa/setuptools/issues/3532
This has been fixed in the new setuptools
release - https://github.com/pypa/setuptools/compare/v65.0.1...main (reverts back the breaking change).
I have decided to reopen this. Now NumPy
advises pinning setuptools
to the recommended version even more clearly and officially in their docs (especially for the projects using numpy.distutils
). Follow https://github.com/numpy/numpy/issues/22135
See -
Either way, our recommendation is to pin setuptools to the last version that worked for you (59.x for numpy itself, maybe 64.0 for others). This is always a good idea to do in your releases. You don't want to find out that things work at release time, and then break afterwards because setuptools or another build-time dependency did a major release.
We already documented this at https://numpy.org/devdocs/user/depending_on_numpy.html#build-time-dependency, although we perhaps should make that a more prominent warning box. The relevant text there is: "For your other build dependencies you can probably be looser, however it’s still important to set lower and upper bounds for each dependency. It’s fine to specify either a range or a specific version for a dependency like wheel or setuptools. It’s recommended to set the upper bound of the range to the latest already released version of wheel and setuptools - this prevents future releases from breaking your packages on PyPI."
I will open a PR to make the warning more prominent, and will advertise the recommendation here again on the mailing list.
EDIT: note that there's a second place we recommend this, in the deprecation warning for numpy.distutils:
@aragilar James, setuptools issues are more your cup of tea. Can you have a look?
Changed the version to <=64.0.0
-
setuptools
version for Python 2.7
, 3.6
, etc. (the CI was failing due to this)setuptools==65.0.0
I think if <=64
passes CI, then merging this makes sense. mesonpy's f2py support is still unclear last time I looked, so I don't think things are ready for to switch away from setuptools yet.
Ok, based on the CI, it looks like a newer version of numpy than is supported is trying to be installed on python 2.7-3.6. I'd be inclined to drop those (3.5 and 3.6 are not longer getting security support), and merge this and do a new release so newer setuptools doesn't break building again.
Thank you for the suggestions! I have removed the support for Python 2.7
, 3.5
, and 3.6
. I think the CI should pass this time.
A gentle bump - @bmcage, @aragilar! (The workflows require approval)
Sorry, I'll try and sort this today.
See https://github.com/numpy/numpy/issues/22135. Right now installing
scikits.odes
results in the following error -The following PR tries to use the latest version of
NumPy
- https://github.com/pybamm-team/PyBaMM/pull/2231