Re: Disabling pip for root?
Le 20/09/13 10:29, Thomas Goirand a écrit : > 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. I did my first packages using Effing Package Management (fpm): https://github.com/jordansissel/fpm You give it a source (pypi), a target (deb) and the name of the resource. Then magic happen and you end up with a .deb. The generated .deb is installable and works fine for the simplest packages. The resulting .deb is not on par with Debian quality though and you need a bunch of additional work to make it acceptable. Maybe have a look at fpm and find out how we can get it improved for the py -> deb case? -- Antoine "hashar" Musso -- 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/523e2d11.7050...@free.fr
Re: Disabling pip for root?
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" 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 > >
Re: Disabling pip for root?
On Fri Sep 20 2013 07:48:07 PM HKT, Paul R. Tagliamonte wrote: > 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. Very good idea indeed! 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/1379678437.1838.5.camel@Nokia-N900-42-11
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 -- 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
Disabling pip for root? (was: PEP 453 affects Debian packaging of Python packages)
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. 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. --- /usr/bin/pip 2013-08-20 00:37:24.0 +0200 +++ pip 2013-09-19 11:11:04.567271401 +0200 @@ -2,6 +2,13 @@ # EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.4.1','console_scripts','pip' __requires__ = 'pip==1.4.1' import sys + +import os + +if os.getuid() <= 100: +print >> sys.stderr, "a nice insult from the sudo insults list?" +sys.exit(-1) + from pkg_resources import load_entry_point if __name__ == '__main__':
