PEP 453 affects Debian packaging of Python packages
Howdy all, Over at the ‘python-dev’ forum, PEP 453 is being discussed. This affects Debian packaging of Python, and packages written for Python. See the discussion thread and take the opportunity to represent Debian https://mail.python.org/pipermail/python-dev/2013-September/128723.html> while this major change to the behaviour of Python packaging is still being specified. Note that we don't need a dog-pile; someone with both knowledge and time to discuss this will find that reasoned arguments work better there. Who can do this? -- \ “I was gratified to be able to answer promptly and I did. I | `\ said I didn't know.” —Mark Twain, _Life on the Mississippi_ | _o__) | Ben Finney -- 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/7wioxyy4zd@benfinney.id.au
Re: PEP 453 affects Debian packaging of Python packages
We don't do "private copies" or "bundled copies" in Debian, so I guess the right way to go for Debian is to have python depend on python-pip and python3 depend on python3-pip? http://wiki.debian.org/EmbeddedCodeCopies -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6gru1so8feclepdxbnyzfshuzjwlo6t6cx-poxrbit...@mail.gmail.com
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 09:38:57 +0200, Paul Wise wrote: > We don't do "private copies" or "bundled copies" in Debian, so I guess > the right way to go for Debian is to have python depend on python-pip > and python3 depend on python3-pip? > We don't do dependency loops without a good reason either (and no, this isn't one). Make it Recommends if you like, though I'd question the value of even that. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- 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/20130918074822.ga13...@crater2.logilab.fr
Re: PEP 453 affects Debian packaging of Python packages
Am 18.09.2013 09:48, schrieb Julien Cristau: > On Wed, Sep 18, 2013 at 09:38:57 +0200, Paul Wise wrote: > >> We don't do "private copies" or "bundled copies" in Debian, so I guess >> the right way to go for Debian is to have python depend on python-pip >> and python3 depend on python3-pip? >> > We don't do dependency loops without a good reason either (and no, this > isn't one). Make it Recommends if you like, though I'd question the > value of even that. the pep doesn't require that but only recommends it, but also points to the hint given by the command-not-found handler which package to install if the command cannot be found. Also the platform package manager should be the preferred way to install packages, not pip, so even a Recommends is a bit strange. Matthias -- 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/523981c9.8020...@debian.org
Re: PEP 453 affects Debian packaging of Python packages
On Wednesday, September 18, 2013 17:16:22 Ben Finney wrote: > Howdy all, > > Over at the ‘python-dev’ forum, PEP 453 is being discussed. This affects > Debian packaging of Python, and packages written for Python. > > See the discussion thread and take the opportunity to represent Debian > https://mail.python.org/pipermail/python-dev/2013-September/128723.html > > while this major change to the behaviour of Python packaging is still > being specified. > > Note that we don't need a dog-pile; someone with both knowledge and time > to discuss this will find that reasoned arguments work better there. Who > can do this? I like the "we'll do updates later, like the ability to securely verify updates." I wouldn't even put this in the archive, let alone in any kind of default install. I also like the approach of we'll add features to python2.7 and call it 2.7 still because we know there's no 2.8. Seems like not really getting the point. Finally, what I read is, other platforms suck, so we're going to try to push Linux distros to a lowest common denominator. Scott K -- 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/6419149.4R8LdaKgJx@scott-latitude-e6320
Re: PEP 453 affects Debian packaging of Python packages
Quoting "Matthias Klose" : Also the platform package manager should be the preferred way to install packages, not pip, so even a Recommends is a bit strange. Yes, a "not-recommended" field would make sense here. As a passionate pip hater I would go for a Conflicts, which finally would make pip uninstallable :~) Next steps: get rid of gem, npm, EPT, ... -- 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/20130918150529.18601sbfufo9b...@webmail.in-berlin.de
Re: PEP 453 affects Debian packaging of Python packages
[W. Martin Borgert, 2013-09-18] > As a passionate pip hater I would go for a Conflicts, > which finally would make pip uninstallable :~) > Next steps: get rid of gem, npm, EPT, ... +1 (unless all these "wheel re-inventors" will speed up a bit - they're still where Linux packagers were 5-10 years ago) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20130918132219.gh12...@p1otr.com
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 03:22:19PM +0200, Piotr Ożarowski wrote: > [W. Martin Borgert, 2013-09-18] > > As a passionate pip hater I would go for a Conflicts, > > which finally would make pip uninstallable :~) > > Next steps: get rid of gem, npm, EPT, ... > > +1 (unless all these "wheel re-inventors" will speed up a bit - they're > still where Linux packagers were 5-10 years ago) And *THIS* is why we get bad reputations. 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. 2) pip workes on *every* supported OS. If you think OSX users or windows users are installing Python modules with dpkg, you're off your rocker. 3) We're *NOT* trying to package every module and put it in the archive, for this, also, is stupid. pip can install from pypi, which *is* such a place. Or even Git checkout URLs. 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. I have two codebases, one uses Django 1.2 and another uses 1.4. I can't co-install the two, since Python isn't smart enough. As a result, I have to use virtualenv. 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. -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte wrote: >On Wed, Sep 18, 2013 at 03:22:19PM +0200, Piotr Ożarowski wrote: >> [W. Martin Borgert, 2013-09-18] >> > As a passionate pip hater I would go for a Conflicts, >> > which finally would make pip uninstallable :~) >> > Next steps: get rid of gem, npm, EPT, ... >> >> +1 (unless all these "wheel re-inventors" will speed up a bit - >they're >> still where Linux packagers were 5-10 years ago) > >And *THIS* is why we get bad reputations. > > 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. > >2) pip workes on *every* supported OS. If you think OSX users or >windows > users are installing Python modules with dpkg, you're off your rocker. > > 3) We're *NOT* trying to package every module and put it in the > archive, for this, also, is stupid. pip can install from pypi, > which *is* such a place. Or even Git checkout URLs. > > 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. > > >I have two codebases, one uses Django 1.2 and another uses 1.4. I can't >co-install the two, since Python isn't smart enough. As a result, I >have >to use virtualenv. > >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. I get why they exist. I object to the mandatory nature of the proposal and the associated be sure to document for your users why you were idiots and didn't ship this. End users should not need these kinds of tools. I think that introducing a package download mechanism that is not cryptographically secured with a promise to later insecurely update the mechanism to have security is crazy talk. The basic message I get from the proposal is "screw you Linux". Scott K P.S. I'm not nominating myself to be the diplomat that talks to upstream for what are probably obvious reasons. -- 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/f334a621-28af-48ab-a188-0f1dd29f1...@email.android.com
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 10:33:52AM -0400, Scott Kitterman wrote: > I object to the mandatory nature of the proposal and the associated be sure > to document for your users why you were idiots and didn't ship this. End > users should not need these kinds of tools. I agree. > I think that introducing a package download mechanism that is not > cryptographically secured with a promise to later insecurely update the > mechanism to have security is crazy talk. I also agree. > The basic message I get from the proposal is "screw you Linux". I think it's a bit more subtle than that - but I do think most Pythonistas tend to forget that end users may not know what pip is - hell, they may not even know what Python is. I think clarifying this upstream would be nice. > Scott K > > P.S. I'm not nominating myself to be the diplomat that talks to upstream for > what are probably obvious reasons. Samesies. On Wed, Sep 18, 2013 at 10:33:52AM -0400, Scott Kitterman wrote: > I get why they exist. I was talking to the people who were advocating for the removal of pip from the archive, not you, Scott :) Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
[Paul Tagliamonte, 2013-09-18] > On Wed, Sep 18, 2013 at 03:22:19PM +0200, Piotr Ożarowski wrote: > > [W. Martin Borgert, 2013-09-18] > > > As a passionate pip hater I would go for a Conflicts, > > > which finally would make pip uninstallable :~) > > > Next steps: get rid of gem, npm, EPT, ... > > > > +1 (unless all these "wheel re-inventors" will speed up a bit - they're > > still where Linux packagers were 5-10 years ago) > > And *THIS* is why we get bad reputations. ok, I forgot to add ";)", but... > 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. tell that to most (sic!) Python app/library authors who recommend to "sudo pip/ez_install ..." in their README files in order to install their software (and tools like pip do not care that given files exist, they just overwrite them (did rpm or dpkg do this 10 years ago?), not to mention that they do that in /usr and not in ~/.local or at least /usr/local (which they should not touch as well, BTW, only admins can, but how can they know that? Why should developer on Windows care about FHS?) Don't get me wrong, I think pip has some valid use cases (f.e. inside virtalenv), I even recommend it sometimes, but forcing us to use it instead of our (much better) tools / breaking things we carefully prepared for our users is just not acceptable. > 2) pip workes on *every* supported OS. If you think OSX users or windows > users are installing Python modules with dpkg, you're off your rocker. Windows has its own distribution system (.exe installers). MacOS has .dmg files (IIRC), Linux distributions have .rpm, .deb, .tar, ... It's not possible for Python developer to get it right on each system so instead of reinventing the wheel and trying to make something that works everywhere they should make it easier for others to convert whatever they provide (tarballs?) into .rpm, .deb or .exe. They should not try to replace our rpm or dpkg! (vide: gems) > 3) We're *NOT* trying to package every module and put it in the > archive, for this, also, is stupid. pip can install from pypi, > which *is* such a place. Or even Git checkout URLs. that doesn't mean they can mess with software we prepared for our users. It takes only one egg or gem to ruin months of Linux packager's work. Admins can use pypi-install to install packages that are not in the archive, we don't need eggs or whls, not in places where it interferes with system software. > 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. nobody forces Python/Ruby/... developers to use libraries prepared by us... and yet they want to force us to use their .eggs and overwrite our files. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20130918154152.gi12...@p1otr.com
Re: [PATCH] Support :any architecture qualifiers for multiarch
Following the “if it didn't happen on a mailing list, it didn't happen”, I repeat here what I said on IRC: 12:26 < kwilk> So I rebuilt src:python-aalib, and I ended up these Depends: "python3:any (>= 3.3.2-2~), libaa1". 12:27 < kwilk> This is wrong; the package only works if the interpreter architecture is the same as libaa1 architecture. 12:27 < kwilk> Please revert this ":any" mess. 12:30 < kwilk> In general, just because a script or a module is pure-Python doesn't mean it doesn't care about interpreter's architecture. 12:30 < kwilk> And there's no way to determine automatically whether it cares or not. -- Jakub Wilk -- 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/20130918162413.ga3...@jwilk.net
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 4:33 PM, Scott Kitterman wrote: > P.S. I'm not nominating myself to be the diplomat that talks to upstream for > what are probably obvious reasons. Too late, upstream folks (for eg Barry Warsaw) are on this list, are DDs and are part of the Debian Python community so you already became our diplomat :) Barry, I hope this thread has not annoyed you at all :) -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6ExYyp22ugLTZV3A4mxWSH2y191-bSWh=se8c8c4y1...@mail.gmail.com
Re: PEP 453 affects Debian packaging of Python packages
On 18 September 2013 08:41, Piotr Ożarowski wrote: > so instead of reinventing the wheel and trying to make something that > works everywhere they should make it easier for others to convert > whatever they provide (tarballs?) into .rpm, .deb or .exe. > >From a developer point of view: this leaves you dependent on other people to get the latest release of your software to users, which can be very frustrating. For instance, I'm a developer for IPython: we made a 1.0 release over a month ago, and there's already been a 1.1 release since then, but Debian unstable still doesn't have either of these. This is not to criticise our packager, who we have a good relationship with, but simply to point out that this system is beyond our control. If we recommend that people use apt/yum/port/whatever to install IPython, they'll get an old package, with bugs that we've already fixed. By contrast, we update the packages on PyPI at release time, so users installing with pip will always get the current version. Thomas
Re: PEP 453 affects Debian packaging of Python packages
Paul Wise wrote: >On Wed, Sep 18, 2013 at 4:33 PM, Scott Kitterman wrote: > >> P.S. I'm not nominating myself to be the diplomat that talks to >upstream for what are probably obvious reasons. > >Too late, upstream folks (for eg Barry Warsaw) are on this list, are >DDs and are part of the Debian Python community so you already became >our diplomat :) > >Barry, I hope this thread has not annoyed you at all :) Barry if far calmer and diplomatic than I am. I hope he (and the other DDs involved in upstream Python) can bring some of the useful parts of this discussion forward upstream. Scott K P.S. Barry has the wisdom of the ages on his side ;-) -- 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/1f736eb3-f6b4-400f-86ef-8cdc1079f...@email.android.com
Re: [PATCH] Support :any architecture qualifiers for multiarch
On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote: > Following the “if it didn't happen on a mailing list, it didn't > happen”, I repeat here what I said on IRC: > 12:26 < kwilk> So I rebuilt src:python-aalib, and I ended up these Depends: > "python3:any (>= 3.3.2-2~), libaa1". > 12:27 < kwilk> This is wrong; the package only works if the interpreter > architecture is the same as libaa1 architecture. > 12:27 < kwilk> Please revert this ":any" mess. > 12:30 < kwilk> In general, just because a script or a module is pure-Python > doesn't mean it doesn't care about interpreter's architecture. > 12:30 < kwilk> And there's no way to determine automatically whether it cares > or not. Nonsense. It's not in the purview of the script/module to care about the architecture of the interpreter. There are cases for which a package that ships a python script / pure python module *does* care about the architecture of the interpreter, but this is *not* because of the script / module itself - it's only because of architecture-specific python extensions included in the same package, which is expressed via a separate arch-specific dependency on libpython; or because of restrictions on the architecture-availability of the other python modules the package depends on, which should be handled by the package manager and *not* hard-coded in the dependencies of the package in question. The operative principle is that the admin should be able to select a /usr/bin/python of any architecture capable of being run on the hardware, and packages that only contain python scripts/modules should Just Work, with apt doing the heavy lifting to ensure the right set of compiled extensions are available to match. This is important for users to be able to successfully cross-grade from one architecture to another, but it's even more important for cross-building, because packages that build-depend on python-using packages need to be able to install the foreign-arch version of those packages *without* changing the architecture of the python interpreter. There are admittedly bugs in apt that caused the first cut of the dh-python support to not work as expected (bug #723586 filed on apt), but that doesn't warrant reverting the :any handling. Piotr has already updated dh-python to address the serious symptoms of bug #723586 to avoid propagating any further breakage while we identify a better solution. As a strawman, if there's a consensus that it's important to preserve the capability to install jessie module packages on top of wheezy's python, we could generate dependencies such as: python:any (>= 2.7.5-5) | python (>= 2.6.6-3) which I think would DTRT in all cases except where you try to cross-install on top of the wheezy python, which is a negligible use case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 3:36 PM, Paul Tagliamonte wrote: > 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. Are they 'borderline useless' because they are normally much older than upstream? I think most development work has no need for latest-and-greatest. P.S.: Thanks for the post. I was unloving the tone of the thread. -- 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/CAA77j2Bzwvys2xpFjQa-OuyqGtpVLazzrk=ihnrtyhjjfmk...@mail.gmail.com
Re: PEP 453 affects Debian packaging of Python packages
W dniu śro, wrz 18, 2013 o 10:57 ,nadawca Tshepang Lekhonkhobe napisał: On Wed, Sep 18, 2013 at 3:36 PM, Paul Tagliamonte wrote: 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. Are they 'borderline useless' because they are normally much older than upstream? I think most development work has no need for latest-and-greatest I think this assumption is wrong. You may want to get security fixes, features or any combination of the above. In my experience debian _packages_ tend to strongly cluster as either well maintained and up-to-date or just dead and forgotten. In the second case I would bet that all real users (developers) are just taking the version from pypi and totally ignore the one in Debian. Also note that for testing many projects rely on tox or other virtualenv-wrapping system (just look at travis-ci for the number of projects that use pypi-originated source ignoring any debian packages) so any developer that works on a project like that is realistically always using a virtualenv for development (for isolation of dependencies and precise version control, note that none of this is about security, it's just about getting the combination that works in a process where change is under the control of the developer) Best regards ZK -- 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/523a1646.8264b40a.26e5.5...@mx.google.com
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 05:41:52PM +0200, Piotr Ożarowski wrote: > ok, I forgot to add ";)", but... Sure, but let's be more careful - I don't want people quoting "Debian Python" people telling people they're going to purge pip from the archive... It's all too often I hear people complain about Debian at PyCon, and I'm getting sick and tired of it. > > 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. > > tell that to most (sic!) Python app/library authors who recommend to I don't need to - this is a pretty commonly accepted fact with pythonistas. Most people know not to run pip with sudo on a sane linux system. > "sudo pip/ez_install ..." in their README files in order to install > their software (and tools like pip do not care that given files exist, > they just overwrite them (did rpm or dpkg do this 10 years ago?), not to > mention that they do that in /usr and not in ~/.local or at least > /usr/local (which they should not touch as well, BTW, only admins can, > but how can they know that? Why should developer on Windows care about > FHS?) > > Don't get me wrong, I think pip has some valid use cases (f.e. inside > virtalenv), I even recommend it sometimes, but forcing us to use it > instead of our (much better) tools / breaking things we carefully > prepared for our users is just not acceptable. I don't disagree, but this isn't a reason to hate on pip. This is a reason to tell the people who wrote this proposal we'd likely not comply, but leave it as an installable component for development work. > > > 2) pip workes on *every* supported OS. If you think OSX users or windows > > users are installing Python modules with dpkg, you're off your rocker. > > Windows has its own distribution system (.exe installers). MacOS has > .dmg files (IIRC), Linux distributions have .rpm, .deb, .tar, ... yawn, see point 1 > It's not possible for Python developer to get it right on each system > so instead of reinventing the wheel and trying to make something that > works everywhere they should make it easier for others to convert > whatever they provide (tarballs?) into .rpm, .deb or .exe. They should > not try to replace our rpm or dpkg! (vide: gems) > > > 3) We're *NOT* trying to package every module and put it in the > > archive, for this, also, is stupid. pip can install from pypi, > > which *is* such a place. Or even Git checkout URLs. > > that doesn't mean they can mess with software we prepared for our > users. It takes only one egg or gem to ruin months of Linux packager's yawn, see point 1 > work. Admins can use pypi-install to install packages that are not in > the archive, we don't need eggs or whls, not in places where it > interferes with system software. > > > 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. > > nobody forces Python/Ruby/... developers to use libraries prepared by > us... and yet they want to force us to use their .eggs and overwrite our > files. yawn, see point 1 I said pretty clearly I don't advocate for this to be used globally. Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 10:57:30PM +0200, Tshepang Lekhonkhobe wrote: > On Wed, Sep 18, 2013 at 3:36 PM, Paul Tagliamonte wrote: > > 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. > > Are they 'borderline useless' because they are normally much older > than upstream? I think most development work has no need for > latest-and-greatest. Well, sorta. The problem here is different major versions have different APIs. If I have to maintain my eons old Django 1.2 app on the same machine as a 1.4 app, I don't want to keep uninstalling and reinstalling packages. It's silly. I wish we shipped wheel files so we can trust the pip installs, but meh. It seems like this, also, isn't something folks here care about for some reason. What's more, it's helpful to have a development env that can match the env that I test stuff in tox with. > P.S.: Thanks for the post. I was unloving the tone of the thread. Samesies :) Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
[Thomas Kluyver, 2013-09-18] > From a developer point of view: this leaves you dependent on other people > to get the latest release of your software to users, which can be very > frustrating. For instance, I'm a developer for IPython: we made a 1.0 > release over a month ago, and there's already been a 1.1 release since > then, but Debian unstable still doesn't have either of these. This is not > to criticise our packager, who we have a good relationship with, but simply > to point out that this system is beyond our control. If we recommend that > people use apt/yum/port/whatever to install IPython, they'll get an old > package, with bugs that we've already fixed. By contrast, we update the > packages on PyPI at release time, so users installing with pip will always > get the current version. I understand your point and I'm not saying PyPI is something bad, I just wish these tools use their own namespace and leave system files alone. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte wrote: >On Wed, Sep 18, 2013 at 05:41:52PM +0200, Piotr Ożarowski wrote: >> ok, I forgot to add ";)", but... > >Sure, but let's be more careful - I don't want people quoting "Debian >Python" people telling people they're going to purge pip from the >archive... > >It's all too often I hear people complain about Debian at PyCon, and >I'm >getting sick and tired of it. Hostile proposals like this don't exactly help build peace, love, and understanding. >> > 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. >> >> tell that to most (sic!) Python app/library authors who recommend to > >I don't need to - this is a pretty commonly accepted fact with >pythonistas. Most people know not to run pip with sudo on a sane linux >system. > >> "sudo pip/ez_install ..." in their README files in order to install >> their software (and tools like pip do not care that given files >exist, >> they just overwrite them (did rpm or dpkg do this 10 years ago?), not >to >> mention that they do that in /usr and not in ~/.local or at least >> /usr/local (which they should not touch as well, BTW, only admins >can, >> but how can they know that? Why should developer on Windows care >about >> FHS?) >> > > >> Don't get me wrong, I think pip has some valid use cases (f.e. inside >> virtalenv), I even recommend it sometimes, but forcing us to use it >> instead of our (much better) tools / breaking things we carefully >> prepared for our users is just not acceptable. > >I don't disagree, but this isn't a reason to hate on pip. This is a >reason to tell the people who wrote this proposal we'd likely not >comply, but leave it as an installable component for development work. If I understood the proposal correctly, security is to be bolted on later. Given the global threat environment, I am against introducing a new code installation mechanism that is not cryptographically verified. It might enter the archive once that's fixed, but I think not before. Scott K -- 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/870d94a5-2cf2-4474-8118-2624f990d...@email.android.com
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte wrote: >On Wed, Sep 18, 2013 at 10:57:30PM +0200, Tshepang Lekhonkhobe wrote: >> On Wed, Sep 18, 2013 at 3:36 PM, Paul Tagliamonte > wrote: >> > 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. >> >> Are they 'borderline useless' because they are normally much older >> than upstream? I think most development work has no need for >> latest-and-greatest. > >Well, sorta. The problem here is different major versions have >different >APIs. If I have to maintain my eons old Django 1.2 app on the same >machine as a 1.4 app, I don't want to keep uninstalling and >reinstalling >packages. It's silly. Sure. It'd be nice if upstreams cared more about API stability. In my experience it's not generally very difficult if developers pay attention to it. >I wish we shipped wheel files so we can trust the pip installs, but >meh. >It seems like this, also, isn't something folks here care about for >some >reason. > >What's more, it's helpful to have a development env that can match the >env that I test stuff in tox with. It shows my background, but when I need older versions of things I fire up a chroot and work in that. I often do that even for the same distro release I'm running to keep things separated. It's quite possible to deal with multiple versions using Debian tools. Scott K -- 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/334d6f02-40c5-4eb2-8661-5258791c2...@email.android.com
Re: PEP 453 affects Debian packaging of Python packages
Am 19.09.2013 00:36, schrieb Scott Kitterman: > > > Paul Tagliamonte wrote: >> On Wed, Sep 18, 2013 at 05:41:52PM +0200, Piotr Ożarowski wrote: >>> ok, I forgot to add ";)", but... >> >> Sure, but let's be more careful - I don't want people quoting "Debian >> Python" people telling people they're going to purge pip from the >> archive... >> >> It's all too often I hear people complain about Debian at PyCon, and >> I'm >> getting sick and tired of it. to be fair, they complain about any system shipped python. > Hostile proposals like this don't exactly help build peace, love, and > understanding. so calling the proposal hostile builds peace, love, and understanding? >>> Don't get me wrong, I think pip has some valid use cases (f.e. inside >>> virtalenv), I even recommend it sometimes, but forcing us to use it >>> instead of our (much better) tools / breaking things we carefully >>> prepared for our users is just not acceptable. >> >> I don't disagree, but this isn't a reason to hate on pip. This is a >> reason to tell the people who wrote this proposal we'd likely not >> comply, but leave it as an installable component for development work. sure, and telling it in this way doesn't raise anyone's blood pressure. > If I understood the proposal correctly, security is to be bolted on later. > Given the global threat environment, I am against introducing a new code > installation mechanism that is not cryptographically verified. It might enter > the archive once that's fixed, but I think not before. so security stays at the same level as before. If you think you have to add something to the pep, then do it and work together with the pep maintainers. Be prepared to spend some time, to work with and understand the windows and macosx ports and the different installers / python distributions. Do you want to do this? Write a pep about integration with system packaging, and submit it, and implement it. Looking at something similar in the Java world you'll find this difficult to get a broad consensus, see the more than once delayed jsr277. The only thing I can see in this thread is that a lot of pressure/opposition is built up on the Debian side, and I currently cannot see why exactly. pip installs (when using the system python) should go to /usr/local, if not then pip should be patched. Maybe give a warning, or require an extra option to run as --yes-run-as-root, or maybe give a hint installing the deb package. Matthias -- 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/523a32fa.7000...@debian.org
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 Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- 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/l1dh0e$al9$1...@ger.gmane.org
Re: PEP 453 affects Debian packaging of Python packages
On Sep 18, 2013, at 09:36 AM, 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. > > 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. I haven't read the whole thread or PEP yet (I'll catch up when I'm a little less tired), but I think these are the most relevant observations. pip, when teamed with virtualenv, is wonderful for development, and works fantastically well on Debian today. pip for global package management (i.e. "root use of pip") on Debian is a terrible idea. It *might* be moderately less terrible if it installed packages in a location not conflicting with the system package manager, and if you had to explicitly enable it in some way. No, I have not thought out all the ramifications of this top-of-head idea. -Barry signature.asc Description: PGP signature
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte writes: > On Wed, Sep 18, 2013 at 03:22:19PM +0200, Piotr Ożarowski wrote: >> [W. Martin Borgert, 2013-09-18] >> > As a passionate pip hater I would go for a Conflicts, >> > which finally would make pip uninstallable :~) >> > Next steps: get rid of gem, npm, EPT, ... >> >> +1 (unless all these "wheel re-inventors" will speed up a bit - they're >> still where Linux packagers were 5-10 years ago) > > And *THIS* is why we get bad reputations. > > 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. Yet it forces me to pass --install-option --user even when called as a an unprivileged user. > 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. Disclaimer: I actually like pip. But the above is really bugging me. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/87bo3pjy4r@vostro.rath.org
Re: Please install /usr/bin/python2
On Monday, September 16, 2013 23:23:30 Kerrick Staley wrote: > On Sun, Sep 15, 2013 at 11:34 AM, Scott Kitterman wrote: > > OK. I think that convinces me it's widely enough spread we ought to fix > > this for Wheezy. I'll take it up with the release managers as it's their > > decision, not mine. > Bug filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723182 > > - Kerrick Thanks. I haven't forgotten this. Work is just really kicking my behind this week. Scott K -- 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/2165176.futgzSXerY@scott-latitude-e6320
