Proposal

I would be in favour of removing setuptools i.e. all setup.py files in 1.6. Meson is our main building tool for some time, teething issues have been found and fixed, and no major blocker issues have been found. We discussed this at the monthly developers meeting today and there did not seem to be any strong objections.

I asked on the Scipy Slack (see message if you are on the Scipy Slack) and got this response from @rgommers:

Now with also Matplotlib and others having switched over, I think you'd be safe with removing setup.py quickly. I am not aware of any blockers in any package that switched so far.

Some projects have removed setup.py already:

• scikit-image has remove setup.py in 0.20 released March 2023: Bite the bullet: remove distutils and setup.py scikit-image/scikit-image#6738
• matplotlib has removed setup.py in 3.9 released May 16: Port build system to Meson matplotlib/matplotlib#26621
• Numpy has removed setup.py in Numpy 2 released June 16: MAINT: remove setup.py and other files for distutils builds numpy/numpy#24519

For local development, I am reasonably confident things should be fine:

• building with Meson has been merged 5 months ago (merged January 23) BLD Add Meson support #28040 and I have been using Meson since then
• most of the developers have been using Meson day-to-day for 1-2 months+ (rough estimate)
• Meson has been presented as our "main building tool" for one month and a half: DOC Mention that Meson is the main supported way to build scikit-learn #29008 (merged May 13).

Potential issues / things to think about

• OpenMP-specific quirk, From the discussion with @rgommers:

  The one thing I can think of that's different in scikit-learn is OpenMP usage. Not sure if that required any special handling beyond linking to llvm-openmp and then running auditwheel & co?

  I can not think about OpenMP-specific issues but happy to hear other opinions. We have released wheels with Meson for 1.5 roughly one month ago, and it doesn't seem like there has been any issues.

• Linux distribution packaging may still rely on setup.py. I am certainly not a Linux packaging expert but it seems like they may not rely on setup.py much:

  • ArchLinux seems to use python -m build see this
  • Fedora pyproject_wheel is used in this which I think means python -m pip wheel from this file
  • Debian I am not sure, the rules seems to use python setup.py config somewhere, but there is also some automatic build detection that should pick Meson IIUC https://wiki.debian.org/Python/Pybuild
  • on this topic, let me ping people that are involved in Linux distribution packaging @mr-c @gspr @sergiopasra that I met in Test failure in i686 with version 1.3.1 #27506.

• any other use case that I didn't think of and that may be using setup.py?

Alternative more conservative option

If we are more comfortable with the more conservative, we could follow what Scipy has done i.e. rename setup.py to _setup.py and keep _setup.py as a fall-back for some time, maybe in 1.6, and remove it in scikit-learn 1.7.

@rgommers said on this:

we did keep _setup.py as a backup for ~2 minor releases, because of the known conda-forge issue, and because our build is very complex and we were the very first package to shift over to Meson, so we weren't 100% sure what surprises we'd encounter. I think there were a few other Linux distros that stayed with setup.py for at least one release cycle, but I think mostly that was a "this is less work right now" than anything fundamental.