Zooko Wilcox-O'Hearn <zo...@zooko.com> wrote: > I'm struggling to articulate something here. When the maintainer of > the stable branch of a platform that I rely on says "The fact that > upgrading to our recent stable release will break this critical > functionality is so-and-so's fault, not ours." this reduces my > confidence in that maintainer. Not because he's wrong! Maybe it > *is* so-and-so's fault. But what I'm looking for in the maintainer > of a stable platform is someone who says "Maybe this wasn't our > fault, but here are the steps we're taking to get you back on your > feet as soon as possible.".
Zooko, I've struggled with this over the last year, in integrating a dozen fairly complicated third-party Python extensions for my system. I've come to the conclusion that the problem is setuptools, and I'm trying hard to remove it entirely from my system. I have no problem with the .egg format or the basic idea, or even the implementation, which I think is pretty nice. It's the structure of the setuptools project that gives me pause. There seems to be one developer, and he seems to be too busy to fix the well-known bugs (like having easy_install ruin the sys.path settings by putting stuff on it in the wrong place -- is that one fixed yet?). In addition, I think the mere existence of setuptools stifles progress on distutils, which is where all the clever tricks of setuptools should properly appear. This would let the whole community of Python developers work on the codebase. I'd like to see a flag on PyPI marking whether the package relies on setuptools, in which case I'll avoid it, or voluntarily entangles itself with setuptools if present (as the only known way to create eggs), or is setuptools-free (my preferred configuration). Frankly, I'd also recommend putting up a warning to developers on PyPI noting these problems with setuptools. Bill _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
