[Distutils] What is the official position on distutils?
Daniel Holth
dholth at gmail.com
Tue Aug 30 14:20:49 EDT 2016
Sylvain's feature seems totally harmless to me. If he wants to detect
features in Python 3.6 and above, more power to him. I love it.
If only it was sufficient to "read" the code for distutils. You will be
single-stepping it in a debugger, I guarantee it.
So let's imagine you wanted to create wheels with distutils without
installing setuptols. Technically you could write a tool do to that without
changing distutils by processing the output of "setup.py install" and
converting distutils' PKG-INFO to METADATA. Please note, the resulting
package has zero dependency information, dependencies are a setuptools-only
feature. It makes me sad to think about how completely drab and pointless
this would be. No offense meant.
Distutils does provide some useful features. If you subclass the build_ext
command and remove the "execute the compiler" step, you can use it to get
the compiler flags expected for C extensions. It also knows how to find the
right version of MSVC on Windows. Very handy:
class no_build_ext(build_ext): def build_extension(self, ext):
def noop_spawn(*args): pass self.compiler.spawn =
noop_spawn build_ext.build_extension(self, ext)
IMO a useful, forward-looking refactor of distutils would take these kinds
of features "one weird trick to link Python modules" of which there are
several, and expose them independently of the command class system. Then
you could feed it into CMake or whatever and build some extensions. No I
don't know exactly how that would work.
It's also unimaginable that we would ever stop needing a working version of
distutils & setuptools, given that we have hundreds of thousands of
existing distributions that use it.
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160830/fa2d4f87/attachment.html>
More information about the Distutils-SIG
mailing list