Re: -nspkg.pth and .pth files - should we get rid of them?
On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr 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: https://lists.debian.org/20150720072935.ga1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr 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: https://lists.debian.org/20150720080015.gb1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
[Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then -- 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: https://lists.debian.org/20150720075655.ge18...@sar0.p1otr.com
Re: -nspkg.pth and .pth files - should we get rid of them?
On 20 July 2015 at 09:00, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. And why should debian-python support that? If one wants to mix things, one is better of using virtualenv. I can see the point of re-using system things for compiled extensions and the interpreter itself, but not for the namespace jungles. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUh_=lwj_dgwfaulrxyt_nrfx3se8jedmx_e6ez_0qa...@mail.gmail.com
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 11:58:07 +0100, Dimitri John Ledkov wrote: On 20 July 2015 at 09:00, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. And why should debian-python support that? Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr 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: https://lists.debian.org/20150720111214.gc1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 13:12:14 +0200, Julien Cristau wrote: On Mon, Jul 20, 2015 at 11:58:07 +0100, Dimitri John Ledkov wrote: On 20 July 2015 at 09:00, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. And why should debian-python support that? Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? My point being, pkg_resources-style namespaces and PEP420-style namespaces are different beasts. Trying to (partly/automagically) convert one style to the other is disruptive and unwelcome. If you want to improve setuptools to support PEP420 namespaces then by all means do that, upstream, without breaking things that work fine today. Thanks, Julien -- Julien Cristau julien.cris...@logilab.fr 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: https://lists.debian.org/20150720111819.gd1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote: Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Because it doesn't really work well when you are supporting both Python 2 and Python 3. For example, if you have the 'foo' namespace with submodules 'bar' and 'baz', you can't write a foo/__init__.py that supports old-style namespaces for Python 2 and PEP 420 style namespaces for Python 3 because in the latter *you can't have an __init__.py at all*. +1 also for getting rid of .pth files as much as is possible. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150720075813.0252b...@anarchist.wooz.org
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 07:58:13 -0400, Barry Warsaw wrote: On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote: Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Because it doesn't really work well when you are supporting both Python 2 and Python 3. For example, if you have the 'foo' namespace with submodules 'bar' and 'baz', you can't write a foo/__init__.py that supports old-style namespaces for Python 2 and PEP 420 style namespaces for Python 3 because in the latter *you can't have an __init__.py at all*. That's exactly why Debian shouldn't mess with it. If upstream is python3-only, they can remove __init__.py and go PEP420. If not, they can use old-style namespaces on both python versions, and there's no reason for Debian to break that IMO. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr 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: https://lists.debian.org/20150720120404.ge1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Jul 20, 2015, at 01:12 PM, Dimitri John Ledkov wrote: Would it be fair to have a goal to only have PEP420 style namespaces in python3 world? I think so, yes. Since we're integrators, I think it's fine for us to make this decision, and deal with any fallout that might occur, though I think that will be rare in practice. Cheers, -Barry pgpYsmk3tdH6t.pgp Description: OpenPGP digital signature
Re: -nspkg.pth and .pth files - should we get rid of them?
On 20 July 2015 at 13:04, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 07:58:13 -0400, Barry Warsaw wrote: On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote: Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Because it doesn't really work well when you are supporting both Python 2 and Python 3. For example, if you have the 'foo' namespace with submodules 'bar' and 'baz', you can't write a foo/__init__.py that supports old-style namespaces for Python 2 and PEP 420 style namespaces for Python 3 because in the latter *you can't have an __init__.py at all*. That's exactly why Debian shouldn't mess with it. If upstream is python3-only, they can remove __init__.py and go PEP420. If not, they can use old-style namespaces on both python versions, and there's no reason for Debian to break that IMO. Would it be fair to have a goal to only have PEP420 style namespaces in python3 world? And if there are upstreams that don't do that now, work with them to achieve this and/or cpython/setuptools/distutils upstream. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjb4+KtnEDAKDTg=kbxnc-hjffeu3suekgq9uzmxwp...@mail.gmail.com
-nspkg.pth and .pth files - should we get rid of them?
There are ~200 -nspkg.pth and ~20 .pth files already in the archive. They slow down interpreter startup, mess with sys.path and provide almost no gain for Debian packages that I can think of. There are only few valid ones: * python-support.pth (and gtk-2.0-pysupport-compat.pth): which hopefully will be removed in this release cycle * wx.pth which selects default wxpython version * Zope2.pth which keeps even worse mess outside dist-packages All other ones can be removed - either after installing directly into dist-packages (PILcompat.pth, GTK ones) or without any change (due to the fact that they're ignored anyway, like HTMLgen.pth or that they do nothing except wasting CPU time - like -nspkg.pth files). Does anyone see a reason not to remove them in dh_python* tools? If not all of them, then at least -nspkg.pth ones? Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) -- 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
