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-...@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-...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
