
Bug report #1: _get_unpatched() returns a module from the system site-packages instead of the module from the PYTHONPATH which ought to have precedence, leading to setuptools-0.6c8 invoking setuptools-0.6a9 in the following stack trace: PYTHONPATH="/home/buildslave/slave-tahoe/dapper/build/support/lib/ python2.4/site-packages" python ./setup.py develop --prefix="/home/ buildslave/slave-tahoe/dapper/build/support" ... Running Nevow-0.9.18/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-rk83KQ/Nevow-0.9.18/egg-dist-tmp-nJ8GSy Traceback (most recent call last): ... File "/home/buildslave/slave-tahoe/dapper/build/ setuptools-0.6c8.egg/setuptools/command/develop.py", line 102, in install_for_development File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/ easy_install.py", line 518, in process_distribution Full details: https://dev.allmydata.com/buildbot-tahoe/builders/dapper/builds/1427/ steps/compile/logs/stdio Bug report #2: _get_unpatched() is way too clever for me to spend time trying to understand and debug right now: def _get_unpatched(cls): """Protect against re-patching the distutils if reloaded Also ensures that no other distutils extension monkeypatched the distutils first. """ What the heck? I don't want to think about that, so instead we're delisting Ubuntu Dapper as a supported platform, since it is the only one of our supported platforms on which we have this problem. Generalized complaint: There are a lot of things that are too clever in setuptools/ easy_install/eggs. Cleverness makes it work in more situations, which is good, but it also means that it is harder to know when it will fail or to understand why it failed. A simpler system that satisfied 90% of the use cases while failing in more obvious ways would be appreciated. (Provided, of course, that those 90% of use cases include the ones that I really care about.) See my earlier post which proposes such a simplification: http://mail.python.org/pipermail/python-dev/2008-March/078243.html Bug report #3: setuptools/easy_install/eggs needs a bug tracker. (Also, of course, a buildbot and a rich suite of automated unit tests.) Some of this message may have been inappropriate for distutils-sig, but what else am I going to do with this issue before I delist Dapper and forget all about it? I would be willing to host a trac instance to serve as a wiki and issue tracker for setuptools, and a buildbot. (But I don't want to have anything to do with subversion -- I much prefer darcs.) Regards, Zooko