In article <4ac9bef5.7080...@taupro.com>, Jeff Rush <j...@taupro.com> wrote: > Lennart Regebro wrote: > > 2009/10/3 Ned Deily <n...@acm.org>: > >> This is not a good experience for users. Unless I'm missing something > >> (and I hope I am), this issue really can't be hand-waved away. > > > > It's unfortunate that this comes in a minor release. > Very unfortunate, as in, it should NOT have happened. And *especially* > without any announcement on python.org or mention on the > python-committers list of something this major. > > But at the same > > time we can hardly avoid fixing bugs just because setuptools isn't > > getting updated at the moment. It's a lose-lose situation. > Setuptools is hardly a minor software tool. Considering that setuptools > is a major focus and key technology of this group, those making changes > to distutils should have tested against setuptools and devised a > solution providing backward compatibility, along with deprecation > warnings. Lennart and Tarek, I know you at least are familiar with this > valuable practice in Zope for years. > > At the least, those making changes to Distutils should, after testing > against Setuptools, widely announced this was coming. It does not > reflect positively on the Distribute team and even hints of > under-the-table intentionality in forcing the community to abandon use > of setuptools. Distribute should win because of superior technology not > forced migration. > > > As I see it this will speed up adaptation of Distribute. Word will > > spread. It's not ideal, but then it's not a perfect world. > > Distribute is very new and there are many folk who will not be adopting > it until it has been out for quite some time. It is a fact of the > conservative nature of some development teams. If setuptools were an > optional, little-used technology in Python it would not be a big deal > but it isn't. It is not appropriate to -force- users to adopt a > particular branch of a fork, except perhaps in the move from Python 2.x > to 3.x where major changes are anticipated and there was no setuptools > for 3.x anyway.
Just another data point: the MacPorts distrbution has just upgraded their python26 to 2.6.3 and now a number of their py26 packages can't be installed because they use setuptools (or depend on another package that uses setuptools) to build C extensions and those fail due to the change in distutils: among others, ipython, numpy, pyobjc2, twisted. Until the MacPorts folks recognize and push out a fix, using the setuptools easy_install to install distribute works - if you know the trick. > Considering that 2.6.3 is messed up in other ways, like displaying the > SVN rc1 tag and a broken logging module, and probably will be > re-released at 2.6.4 very shortly, perhaps we can get this -at least- > into the Python docs and maybe introduce backward compatible hooks into > distutils to support setuptools. I've opened an issue of the main Python issue tracker outlining the problem, primarily for the benefit of affected users who search the tracker: http://bugs.python.org/issue7064 -- Ned Deily, n...@acm.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
