Enscons uses parts of distutils to get compiler flags and so on but does not use Extension() to do the actual compiling. There might be a cleaner way to do it that I was not able to find. There could be a cleaner separation between parts of distutils related to how Python itself was compiled and the part that does the actual compiling. The sysconfig module attempts to do at least part of this.
distutils also knows about some compiler tricks like generating symbol tables for Windows, that are not easy to re-use or invoke separately. Someone could catalog these tricks and techniques and refactor the useful ones into a reusable library. I don't have a great sense of how to do it. https://bitbucket.org/dholth/enscons/src/tip/enscons/cpyext.py?at=default&fileviewer=file-view-default On Wed, Sep 27, 2017 at 11:36 PM Nick Coghlan <ncogh...@gmail.com> wrote: > On 28 September 2017 at 06:00, xoviat <xov...@gmail.com> wrote: > > That's actually an interesting idea though: for Python 3.7 distutils -> > > _distutils (and then setuptools is required for building). For/against? > > distutils works fine for its original purpose (building components for > the system Python in Linux distros), so we still need to avoid > breaking that. setuptools is only essential if you want full support > for modern *Python* level packaging features (PEP 376 install > metadata, venv compatibility, wheel files, etc), and a lot of Linux > system components simply don't worry about those things, and rely on > their system level equivalents instead (e.g. the RPM/deb databases, > chroots and containers, RPM/deb files) > > However, what *could* be interesting is a proposal to move distutils > to the "ensurepip" model, where rather than maintaining distutils > directly as part of CPython, the CPython build process instead runs > setuptools/distutils from a bundled wheel file. Doing that would > entail having setuptools actually start installing a copy of distutils > into site-packages: older CPython releases would ignore it by default > (since the stdlib version would shadow it), while 3.7+ would offer > either "python3 -m ensuredistutils" or "python3 -m ensuresetuptools" > (bikeshed to be painted via the PEP process) to install the > setuptools-provided version. > > I'm not claiming actually doing that would be particularly easy - I > just think it's the most viable path to get us away from the current > version coupling between the build infrastructure in distutils and the > runtime support infrastructure in the rest of the standard library, > and to avoid maintaining two distinct copies of distutils indefinitely > (one in the stdlib, one in setuptools). > > That approach wouldn't even entail any *new* bundling at the CPython > level, as while it's currently formally an implementation detail > (pending potential removal in a post-PEP-517 world), setuptools is > already bundled as part of the support infrastructure for ensurepip: > https://github.com/python/cpython/tree/master/Lib/ensurepip/_bundled > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
