Re: [pygtk] PyGObject directory issue again, taking a stand

[Tomeu Vizoso <tomeu sugarlabs org>]

On Fri, Nov 19, 2010 at 13:30, Dieter Verfaillie
<dieterv optionexplicit be> wrote:
> Quoting "John Palmieri" <johnp redhat com>:
>>
>> If you feel this is a really bad idea, speak now.
>
> It's a great idea, maybe a bit overdue even ;)
> Some questions/thoughts:
>
> * Where are the following going to be installed?
>    * tests and testhelper?

Do we really need to install those?

>    * codegen/
>        I suppose this one can stay in site-packages/gtk-2.0
>        for as long as the static bindings are maintained?

Sounds good to me.

>    * dsextras.py
>        As far as I know, this is only used by the mswindows
>        specific setup.py files to build various "static bindings"
>        installers (pygobject itself, but also pygtk, pygoocanvas,
>        ...) for that platform?
>
>        If that's the case it could stay in
>        site-packages/gtk-2.0 for as long as the static bindings
>        are maintained. Once we get rid of them, we could stop
>        installing it entirely, but keep it in the pygobject source
>        distribution next to the setup.py file (so we can still
>        build the pygobject package for windows).
>
>        If it is used for other things (like I said, I'm not
>        sure...) is it going to be installed directly into
>        site-packages? Personally, I don't like modules living
>        directly in the site-packages directory. We could make
>        it a python package though: site-packages/dsextras/__init__.py
>        Bonus: it becomes possible to do just about anything with
>        dsextras it in the future.

No idea myself.

> * Can we take it a step further and stop installing the .pth file
>  entirely? Nothing will change for gio, glib, gobject and gi. You'll
>  still be able to import those packages by simply stating
>  'import gio', etc. It does, however, change things for the static
>  gtk (, goocanvas, gtksourceview, ...) bindings:
>  'import pygtk; pygtk.require('2.0')' becomes a real requirement again,
>  as it always should have been [1].

But that would break some existing apps that still use static bindings, right?

>  Building on the above, we could have part of a reliably method to
>  detect [2] if the static bindings get imported but you already have
>  imported gi (but not necessarily the inverse!) and raise a
>  warning/error 'you should not mix the old static bindings with the
>  new introspected bindings'.

It can be a bit tricky because the problem is only with mixing
wrappers for the same classes. As in, using the static bindings for
GStreamer in an app that uses Gtk+ through introspection should be
safe.

Regards,

Tomeu

> mvg,
> Dieter
>
> [1] The presence of the .pth file means the logic for pygtk.require('2.0')
> gets bypassed entirely as the gtk-2.0 directory gets placed on sys.path
> on interpreter startup the moment it reads the pygtk.pth file.
> It got introduced in Makefile.am when pygobject got split from pygtk
> which appears in the pygobject history here:
> http://git.gnome.org/browse/pygobject/commit/?id=551a38178f7e66f215980fb01200472c8e6d3cd4
>
> And got removed at the same time from pygtk here:
> http://git.gnome.org/browse/pygtk/commit/?id=dca42f447c6a80eb99c475beeedfee08b6454924
>
> It's inception can be traced back to this commit:
> http://git.gnome.org/browse/pygtk/commit/?id=d7adb10beaad9e2f1abddfa597dd0f88004744a4
>
> Sadly, that last commit's message isn't clear why the .pth file got
> included. I have a feeling it might have been simply a convenience
> for the developer at that time?
>
> [2] an example when the .pth file is removed:
>>>>
>>>> import sys
>>>> import gi
>>>> print True in [x.endswith('gtk-2.0') for x in sys.path]
>
> False
>>>>
>>>> import pygtk
>>>> pygtk.require('2.0')
>>>> print True in [x.endswith('gtk-2.0') for x in sys.path]
>
> True
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> pygtk mailing list   pygtk daa com au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
>