On 4 Sep 2013 07:20, "M.-A. Lemburg" <m...@egenix.com> wrote: > > On 31.08.2013 17:56, Nick Coghlan wrote: > > setuptools definitely has its issues, but it's still substantially superior > > to distutils, and has the critical virtue of behaving the *same* in all > > currently supported versions of Python. Consistency across platform > > versions is something you really want in a build tool, and is something a > > standard library module like distutils can never provide. As one of the > > most conservative Linux vendors, even Red Hat has acknowledged this key > > point by creating the Red Hat Developer Toolset to provide a more > > consistent build experience across different RHEL versions. Microsoft (with > > Visual Studio) and Apple (with XCode) have long worked the same way. > > I think you're overestimating the usefulness of setuptools here. > > setuptools only extends distutils in various ways, it doesn't > replace it. And it doesn't do a good job at extending it, since > it monkey patches distutils in areas where monkey patching > is not necessary (*). > > distutils does provide a pretty straight forward way to extend it, > adding new commands to it and new options to existing commands. > I've been extending distutils for many many years in mxSetup.py > (which is part of egenix-mx-base). It's been working great and > I only rarely had to revert to monkey patching in order to get > something implemented. > > 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. > > BTW: I'm not sure where you get the idea from that setuptools > behaves the same across Python versions or platforms. It simply > inherits the distutils changes in each version and thus exhibits > the same problems (if any) that you see with distutils itself. > > (*) Monkey patching is necessary in a few places, but most of those > could be fixed by splitting out method code into new methods which can > then be overridden to provide the new functionality. Note that > this is a classical problem with OO code, there's nothing special > here w/r to distutils.
Sure, it's *possible* someone could publish a "better setuptools" that avoids unnecessary monkey patching, leaves out easy_install and separates pkg_resources out into its own distribution. However, setuptools, for all its flaws, already clears the "good enough" bar in most cases, at least as far back as 2.6 (and likely earlier). Any new standards are going to have to be supported in setuptools *anyway* due to the number of projects that rely on it explicitly for the opt-in features like dependency declarations and entry points, so it seems expedient to me to avoid duplicating that effort. There are also existing projects like bento with a setup.py that can cope with vanilla distutils *and* with setuptools, but may not cope with a new setuptools replacement that does things a bit differently again. The recommendation to use setuptools and the requirement for all distributions to at least *tolerate* setuptools being imported into the same process as their setup.py is an entirely pragmatic one in order to bootstrap the migration to the next generation dependency management system by using the *current* dependency declaration system. Cheers, Nick. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Sep 03 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