-nspkg.pth and .pth files - should we get rid of them?

[Piotr Ożarowski]

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

[Julien Cristau]

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....@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances


--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2015072007...@sh76.dev.logilab.fr

[Piotr Ożarowski]

[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-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150720075...@sar0.p1otr.com

[Julien Cristau]

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....@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2015072008...@sh76.dev.logilab.fr

[Dimitri John Ledkov]

On 20 July 2015 at 09:00, Julien Cristau <julien....@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-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/CANBHLUh_LWj_dGwfaULrxyt_...@mail.gmail.com

[Julien Cristau]

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....@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....@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2015072011...@sh76.dev.logilab.fr

[Julien Cristau]

On Mon, Jul 20, 2015 at 11:58:07 +0100, Dimitri John Ledkov wrote:

> On 20 July 2015 at 09:00, Julien Cristau <julien....@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....@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2015072011...@sh76.dev.logilab.fr

[Barry Warsaw]

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-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150720075...@anarchist.wooz.org

[Julien Cristau]

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....@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2015072012...@sh76.dev.logilab.fr

[Dimitri John Ledkov]

On 20 July 2015 at 13:04, Julien Cristau <julien....@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-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/CANBHLUjb4+KtnEDAKDTg=KBxNc-hjFfEU3s...@mail.gmail.com

[Barry Warsaw]

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