[Distutils] [Python-Dev] 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 Distutils-SIG mailing list