Repository navigation
Adopt distutils #417
Description
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
Setuptools builds on the distutils framework of the Python Stdlib. Doing so has benefits of depending on a standard, extensible framework, but also has downsides, such as limiting the advancement of distutils (across many Python versions) but simultaneously adding monkey patches to patch bugs in distutils.
I'd like to consider if Setuptools should adopt distutils (or a version of it). Doing so would decouple Setuptools from distutils, freeing Setuptools from the constraints of distutils and freeing distutils from the expectations of Setuptools.
Doing so would allow distutils to adapt at the same pace as Setuptools, addressing issues and vetting patches that could be ported back to distutils in CPython.
I've once proposed this idea and it was promptly dismissed by @RonnyPfannschmidt. Why is vendoring distutils in Setuptools not an option?
Activity
jaraco commentedon Oct 25, 2017
@xoviat : To answer your question from the other ticket, I'd very much appreciate a PR.
jaraco commentedon Nov 12, 2017
Distutils branch now exists, created against the latest master. Is that what you had in mind?
15 remaining items
ncoghlan commentedon May 27, 2018
While CPython as a whole has many contributors, we don't have many folks contributing to
distutilsany more - folks need build tools that let them target currently deployed versions of Python, whichsetuptoolsprovides, butdistutilsreally doesn't.So the challenge for pypa/packaging-problems#127 is as follows:
distutilsis no longer in the standard library per se, but is instead bundled the way we bundlepip(i.e. by installing it from a wheel at Python installation time).distutilsisn't in the standard library), we'd like the "real" distutils code to live insetuptools, and the code you get when you doimport distutilsto just be a backward compatibility shim that aliases thesetuptoolscomponents into the right placedistutilsis still in the standard library), thensetuptoolswill still need to do its monkeypatching magic to allow plain distutils projects to emit the installation database metadata and to be built as wheel archivesThe scope of the eventual
distutils-compatshim probably wouldn't need to be the full distutils API, but it wouldn't be the empty set either.So @jaraco's suggestion sounds like a reasonable starting point to me: give
setuptoolsits own pre-patched copy ofdistutilsso it can work on adistutils-free copy of Python, without providing an importabledistutilsfacade.Building a suitable facade (with a
setuptoolsdependency) would then be part of removingdistutilsfrom the standard library.pganssle commentedon May 27, 2018
As an aside about implementing this, I could be way over-estimating the abilities of the average student, but this feel like approximately the right size project for a GSoC student. Too late for this year I'm sure, but if this isn't done by next year we might want to consider applying.
RonnyPfannschmidt commentedon May 27, 2018
@pganssle while you consider the abilities of a student right, i believe there is an underestimation on the complexity of legacy not so nice apis and their interaction in setuptools - unfortunately both codebases are already hard to navigate, and their interaction makes things even more tricky
pradyunsg commentedon Dec 6, 2019
As a past GSoC student, the thing that hits hard "right in the face" is the technical debt -- working with and around it, is very much not something that formal education prepares students for.
Anyway, now would be a good time to get started on figuring out GSoC-sized projects within the PyPA and identifying mentors for them, if we're interested in having projects under PSF's GSoC umbrella for 2020 with decent amount of preparation/planning.
jaraco commentedon May 31, 2020
In #2143, I've drafted a PR that adopts Setuptools from CPython master, retaining history and attribution. This is essentially the second step outlined in pypa/packaging-problems#127. I've asked a few key contributors to review, but I welcome review or comments or questions from anyone.
hugovk commentedon May 31, 2020
Typo, it's really: pypa/packaging-problems#127 :)
jaraco commentedon Jul 3, 2020
The Setuptools 48 release incorporates the fix and closes this issue, although there is still a lot of work to do to actually merge the functionality and remove the monkey patching.
Add tests capturing expected distutils behavior. Ref #417.
77FN7 commentedon Oct 16, 2022
tidelift.com/funding/github/pypi/setuptools