On 9/4/20 12:22 PM, Paul Moore wrote: > I believe that's correct. My main concern here is that removing > distutils from the stdlib won't have made that problem any better, it > will simply have transferred the responsibility onto the setuptools > maintainers. While I assume that they are comfortable with that, I > suspect they may take a different position on backwards compatibility > than core Python does (not least because one copy of setuptools has to > support multiple python versions, including alternative versions like > PyPy, whereas the stdlib copy only needs to handle the version of > Python it's distributed with). I think that it's /basically/ true that this move does transfer that responsibility over to setuptools, and I'm pretty sure that this is effectively handing over a big deprecation to deprecation specialists, since — at least as long as I've been involved with it — the process of maintaining setuptools is dominated by deprecating things (we do bugfixes and add features as well, of course, but there's a lot more to deprecate than in your typical project).
That said, there are two major advantages to moving distutils into setuptools as the first step in making these "backwards-incompatible" changes (moving distutils into PyPI has similar advantages): 1. Deprecation notices start going out to /all/ supported versions of Python /immediately/ if they are using setuptools, making it easier to get the ecosystem to move together. 2. The fact that setuptools supports many versions of Python decouples the upgrade cycle of setuptools from the upgrade cycle of Python. Users can opt-in to new features by pinning a minimum version of setuptools (allowing them to take on migrations /without/ needing to upgrade their Python version), and if setuptools removes a feature they are counting on, they can pin a maximum version of setuptools mostly without disrupting their ability to upgrade Python versions. Related to this, setuptools can (and does) do more frequent updates, so it's easier to make a quick release undoing major breaking changes (or adding a new feature to work around them, etc). > I think the arguments in favour of this PEP from CPython's point of > view are fairly strong, but the arguments from the point of view of > the wider Python ecosystem are much less clear. I mostly agree that this is more useful for the people maintaining setuptools and distutils than it is for consumers of these packages, though that's not necessarily a bad thing. The downside is that we're going to make a bunch of breaking changes over the next few years (hopefully well-documented and with clear migration paths). The upside is that it will be easier for people to reap the benefits of the work we're doing to improve the packaging ecosystem (standardized build artifacts, bugfixes, etc). > Paul > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/QRCA2AHOGZMQS45DANW4UGA63WTMJVQ6/ > Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/T7WR2LH4KSRN2PJE5C6Q35CVMLQ6MLFY/ Code of Conduct: http://python.org/psf/codeofconduct/
