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 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?
[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 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 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?
On 20 July 2015 at 09:00, Julien Cristau 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 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 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 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 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 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: package with multiple modules name spaces
[PICCA Frederic-Emmanuel, 2015-07-17] > I am working on a source package pymca, which will provide 2 modules > PyMca5 and fisx [...] > export PYBUILD_NAME=pymca5 > %: > dh $@ --with python2,python3 --buildsystem=pybuild you can 1) invoke dh twice with different set of options (if these modules are in two different directories or use two different setup.py files/options) or 2) (ab)use --ext-dest-dir/--ext-pattern to move some files to different package, f.e. like this: export PYBUILD_EXT_DESTDIR_python2=debian/python-fisx export PYBUILD_EXT_DESTDIR_python3=debian/python3-fisx export PYBUILD_EXT_PATTERN='.*/fisx/.*' but in your case: you should package fisx¹ as a separate source package and remove fish from pymca5 upstream tarball (hint: uscan does that for you if you use DEP5 format in debian/copyright and fill in Files-Excluded header in there) [¹] https://github.com/vasole/fisx -- 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/20150720121007.gg18...@sar0.p1otr.com
Re: -nspkg.pth and .pth files - should we get rid of them?
On 20 July 2015 at 13:04, Julien Cristau 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
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:package with multiple modules name spaces
Hello, thanks for your reply > you can > 1) invoke dh twice with different set of options (if these modules >are in two different directories or use two different setup.py >files/options) the use the same setup.py for now... > or > 2) (ab)use --ext-dest-dir/--ext-pattern to move some files to different >package, f.e. like this: > export PYBUILD_EXT_DESTDIR_python2=debian/python-fisx > export PYBUILD_EXT_DESTDIR_python3=debian/python3-fisx > export PYBUILD_EXT_PATTERN='.*/fisx/.*' These is also data so I will try to find a way not to abuse and use a custon install target for each modules without pybuild > but in your case: you should package fisx¹ as a separate source package > and remove fish from pymca5 upstream tarball (hint: uscan does that for > you if you use DEP5 format in debian/copyright and fill in > Files-Excluded header in there) I agreed with you , I am discussion with the upstream which is in holydays now :) At the end I think thaht both packages will be distributed separatly. But who knows how long this temporary situation will last... Cheers Frederic -- 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/a2a20ec3b8560d408356cac2fc148e53b2178...@sun-dag3.synchrotron-soleil.fr
