On Sun, Jan 16, 2022 at 10:40 PM Sandro Tosi <sandro.t...@gmail.com> wrote:
> > 4. Write a docs page with migration info on how to deal with the > deprecation, and update it before the 1.23.0 release. > > i think this will be extremely important. Just to give you the current > POV of debian projects using numpy.distutils: > > - > https://codesearch.debian.net/search?q=numpy.distutils+-package%3Anumpy&literal=0&perpkg=1 > (there are 74 of them) > - > https://codesearch.debian.net/search?q=from+numpy+import+.*distutils&literal=0 > (only one "from numpy import distutils") > > hope this could help you come up with a smooth deprecation process :) > Thanks Sandro, that is helpful. I had a look at all those 15 pages of search results: PyPy: just a few patches for numpy <1.11.2 which can be dropped Silx: uses Configuration (i.e., nested setup.py's) Electrum: just a few patches for numpy <1.11.2 which can be dropped Setuptools: just a few patches for numpy <1.11.2 which can be dropped python-hdf4: nothing special, can be switched to setuptools pybigwig: uses `get_info('npymath')` to (optionally) build against numpy - this may need to be added to setuptools python-pot: uses private numpy.distutils compiler support; can be switched to setuptools or vendored petsc4py: small setup.py, but uses Fortran support and Configuration - should probably switch build system basemap: uses Extension, can just switch to setuptools openexr: just queries numpy include dirs in an incorrect fashion, should use `numpy.get_include` rocketcea: nothing special, can just switch to setuptools brian: no usage, just a string `numpy.distutils` in docs libvigraimpex: just queries numpy include dirs in an incorrect fashion, should use `numpy.get_include` gpaw: some weird monkeypatching in shell scripts of numpy's BLAS/LAPACK support, can probably just be dropped pyferret: uses Extension, can just switch to setuptools adolc: just queries numpy include dirs in an incorrect fashion, should use `numpy.get_include` theano: uses BLAS support, they should probably vendor `system_info.py` (or switch build systems) scikit-image: uses Configuration scikit-ffm: uses Configuration, but only two setup.py files - easy to consolidate in a single setup.py and switch to setuptools pywavelets: no longer uses numpy.distutils pybind11: just a code comment, no numpy.distutils usage sfepy: uses Configuration nibabel: only one usage in a test case, just drop it versioneer: just a mention in the docs cypari: just a patch for numpy < 1.11.2, can be dropped blender: just a patch that can be dropped scikit-learn: uses Configuration and build_ext modification for parallel compilation nipype: minor usage of Configuration, can be dropped guiqwt: uses Extension but no longer has Fortran code, so can switch to setuptools The summary of this is: if Configuration is added to setuptools, 90% of packages are fine switching to setuptools. Scikit-learn is planning to follow SciPy and move to Meson. Theano is the only real consumer of numpy.distutils BLAS/LAPACK support, which they should vendor if they don't want to switch build systems. There are no other serious issues here. I'm sure there are some more packages out there relying on Fortran support in particular, they are best off moving to Meson or CMake. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
