[Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
Paul Moore
p.f.moore at gmail.com
Wed Jul 15 17:59:56 CEST 2009
2009/7/15 David Cournapeau <cournape at 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.
More information about the Python-Dev
mailing list