Re: Disabling pip for root?
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
Reply to: