Re: [pygtk] PyGObject directory issue again, taking a stand
- From: Tomeu Vizoso <tomeu sugarlabs org>
- To: Dieter Verfaillie <dieterv optionexplicit be>
- Cc: python-hackers-list <python-hackers-list gnome org>, pygtk <pygtk daa com au>
- Subject: Re: [pygtk] PyGObject directory issue again, taking a stand
- Date: Tue, 23 Nov 2010 10:20:57 +0100
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/
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]