Re: PEP 453 affects Debian packaging of Python packages
Hi Paul,
> I don't understand the pip hate. Why don't you guys try and, you know,
> figure out *why* these tools were invented. It (for sure) is overly
> simplistic, but it's there for a reason.
It's pretty obvious why these tools were invented -- I think everyone
appreciates the difficulties of installing and distributing software across
different platforms, particularly legacy ones with no native concept of
package management. I think it's also safe to assume that the python
packaging list is probably acutely aware of API problems in python modules
that would make it useful in virtualenvs too.
However, we're currently in a situation where users can very easily make an
absolute mess of their set up without realising that's what they are going
to do and it then becomes Debian's user support problem. We see this on a
regular enough basis -- packages stop working and the python stackdumps show
modules with incompatible APIs being loaded from /usr/local/. (#703874 is
just one example of this that I have to hand -- I'm sure the BTS has many
more and we see a few per week like this in #debian)
Who gets the blame for mess made? The Debian project and its developers. Who
ends up helping users clean up the mess? The Debian project and its
developers. Pip can as useful as it wants in virtualenvs but it already has
a lot of historical baggage attached to it that is mostly associated copious
amounts of time spent trying to fix the mess it makes on Debian machines.
That's why you have pip hate.
For better or for worse, proposals to make further use of pip carry all this
historical baggage with them. As suggested elsewhere in this thread changing
pip so that it was difficult to do things system-wide would help with this.
cheers
Stuart
PS While not directly related to pip (but in a quite similar vein), in the
last week, I've seen the exact problem below *twice*:
"I tried to install python2.7 on my squeeze box like this
https://mail.python.org/pipermail/python-list/2011-May/603818.html
and now I get:
update-alternatives: error: cannot stat
/usr/bin/python2.7/bin/python2.7: Not a directory
Help!"
tl;dr: trying to install jessie's python into squeeze doesn't work out so
well and creating alternatives is harder than it looks when you're blindly
copying instructions from the web. Suggestions on upstream mailing lists
from people who either don't know what they're doing or don't fully explain
the dangers aren't always the best things to follow. *sigh*
PPS Virtualenvs are another commonly cited use case for pip, but virtualenvs
are mostly a short way of saying "we don't care about API stability" (your
own story of the incompatibilities of django versions is an illustration of
this); they're an interesting technical solution to a poor development model
that focuses on developers getting high on finding the perfect solution at
the expense of the users of the code. Every user of that module has to
either: keep altering their own code to match new APIs, or try to insulate
their code from API changes by using virtualenvs, or NIH it instead. So
sure, virtualenv+pip is a valid use case for pip, but it should hardly be
considered the pinnacle of python's achievements.
But I think I'll leave the rest of that rant (and the bit about what you
shoudl do in a virtualenv when you need both modules A and B but module A
needs C version 1.0 and module B needs C version 1.1) for another day.
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint BE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8
Reply to: