2009/7/15 David Cournapeau <courn...@gmail.com>: > As was stated by Debian packagers on the distutils ML, the problem is > that docutils 0.5 breaks packages which work with docutils 0.4 in the > first place. > > http://www.mail-archive.com/distutils-sig@python.org/msg05775.html > > And current hacks to work around lack of explicit version handling for > module import is a maintenance burden: > > http://www.mail-archive.com/distutils-sig@python.org/msg05742.html > > setuptools has given the incentive to use versioning as a workaround > for API/ABI compatibility. That's the core problem, and most problems > brought by setuptools (sys.path and .pth hacks with the unreliability > which ensued) are consequences of this. I don't see how virtualenv > solves anything in that regard for deployment issues. I doubt using > things like virtualenv will make OS packagers happy.
So, I think what you're saying is: - The real issues is packages not maintaining backward compatibility (I agree) - Setuptools is a workaround (I agree, at least it's *one* workaround) - Virtualenv isn't a workaround (I don't know virtualenv, I'll take your word for it) Three points: - When building *applications*, bundling everything (py2exe-style) is an alternative workaround - universal on Windows, apparently uncommon on Unix/Linux. - When managing multiple packages in a "toolkit" style interactive Python installation, I'm not aware of a good solution (other than avoiding core that hits this issue in the first place). - I do not believe that it's clear that sanctioning the setuptools workaround as the "right" approach by building it into the Python core/stdlib is the right thing to do. Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
