Why not see if upstream pip wants to add an optional dpkg install method when using root on a dpkgey system? Slightly hackish but at least itd reduce suck.
Or disable root pip. Either way is fine T On Sep 20, 2013 4:30 AM, "Thomas Goirand" <z...@debian.org> wrote: > On 09/19/2013 05:26 PM, W. Martin Borgert wrote: > > On 2013-09-18 09:36, Paul Tagliamonte wrote: > >> 1) pip isn't for global package management, for this is stupid. If we > >> disabled root use of pip, I think we'd all be a bit happier. > > > > Very quick and very dirty patch attached. > > > >> 4) Python modules from dpkg are borderline useless for developers. We > >> package modules so that apps can use them, not so that people can > >> develop with them. > > > > That is maybe my problem with pip: Developers tend to use every Python > > library in every version they like from PyPI. > > I couldn't agree more with that. In OpenStack, I see upstream writing: > > package-name==1.2.3 > > Or even: > > package-name>=1.2.3,<=1.2.4 > > when in fact, there's not even a 1.2.4 released, and the developer just > writes this "just in case". I've been fighting a lot of these. That's > really bullshit dependency management, and fighting with it is > exhausting, patching endelessly the requirements.txt file. Especially > tiring when dealing with nearly a hundred package. > > Worse, some upstream developers don't understand that writing a > dependency like <= 1.2.4 in a requirements.txt file does *not* fix the > problem for a distribution, and that if 1.2.5 is available in the > distro, we will *not* go back and package an older version. This is the > kind of trouble we have with pip, and it's not going away. > > How can we get rid of this, or at least keep it to a bearable minimum? > Well, unfortunately, I think that there's no other way but educating > upstream coders. But also, it'd be super nice if the people upstream for > Python itself understood it and could see from the point of view of a > distribution like Debian. Seeing that they push for even more pip crap > shows that they didn't get it. > > > As a project leader I > > generally have to think about deployment and this means: Use Debian > > stable and backports! Only for long-term projects the next Debian > > stable release might be relevant. But if you have a dozen or so > > libraries installed by pip, there are libraries that will not be > > packaged for Debian and the deployment is wrecked. > > It's really not hard to package some Python modules for Python. Having a > tool that does it automatically - even not very well -, like debpear > does, can solve this kind of trouble. Giving access to this kind of > tools to a wide user base can also help solving the "oh, but that module > isn't available in Debian" kind of problem. > > Thomas > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/523c0780.7010...@debian.org > >
