On 03.09.2013 23:57, Paul Moore wrote: > On 3 September 2013 22:20, M.-A. Lemburg <m...@egenix.com> wrote: > >> IMO, a much better way forward would be to integrate useful setuptools >> changes right back into distutils, so that the monkey patching >> no longer happens and python-dev can officially bless those >> set of changes. >> > > I'm curious about this possibility. One thing that would ease > experimentation in this area, and which has certainly been discussed > elsewhere in this thread, would be if there was a clearly defined set of > setuptools facilities that are missing from distutils, and which the > "modern infrastructure" relies on. Off the top of my head, the following > items would definitely be needed: > > 1. An extension to the install command to supply a list of the installed > files (the --record feature of setuptools)
This already exists in distutils' install command. > 2. A bdist_wheel command This is not part of setuptools, but yes, this should be added as well. > 3. Updates to the install (or maybe bdist_egg) commands to emit Metadata > 2.0 and dist-info metadata Should be easy to do (mostly copy&paste). > 4. An install_scripts command that created script wrappers from metadata > (may not be needed if the only supported route to install is via wheels) Adding new commands is really easy in distutils, so that's not much of a problem either: distutils has a "cmdclass" mechanism which allows to easily register new commands or override existing command classes. We've been using this in mxSetup.py to customize distutils commands and add new commands such as an autoconf mechanism in the build process, a C library build process (implementing the "./configure; make" dance), bdist_prebuilt or uninstall. > To be honest, these extensions do seem relatively achievable. But I don't > know if they are complete - can the advocates of setuptools clarify what > facilities of setuptools are needed beyond these (with an indication of > where they are used in the build toolchain). > > There are other features of setuptools that I can see would be relevant > (for instance, version parsing and requirement checking) but these seem to > me to be more in the nature of utility library features than distutils > enhancements per se. I'd fully expect that such code could easily be > extracted from setuptools (indeed, it may be that all of that code is > isolated in pkg_resources already) without needing any of the distutils > monkeypatching/extensions. > > It may be that such an approach is reinventing the existing wheel that is > setuptools, and indeed it may never go anywhere - but it is an interesting > alternative train of thought. It's not about reinventing the wheel, it's taking the good bits from setuptools and moving them into distutils to make them standard for Python 3.4+, allowing setuptools to stop monkey patching distutils and extensions to stop relying on a setuptools patched distutils. I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
