Re: What is the significance of pygtk.require('2.0')?
- From: Tomeu Vizoso <tomeu vizoso collabora co uk>
- To: Dieter Verfaillie <dieterv optionexplicit be>
- Cc: python-hackers-list gnome org
- Subject: Re: What is the significance of pygtk.require('2.0')?
- Date: Wed, 10 Nov 2010 14:40:42 +0100
On Mon, Nov 8, 2010 at 14:13, Dieter Verfaillie
<dieterv optionexplicit be> wrote:
> Hi,
>
> I've been reading this discussion on the future of our beloved
> pyg* bindings and would like to react to the bug report referenced
> by Tomeu [1] and the patch proposed in that bug report [2].
>
> The patch proposes to install the gi package into site-packages/gi,
> instead of site-packages/gtk-2.0/gi. As the gi package contains a
> python c extension, it gets linked to the underlying
> libg(lib, object, ...) libraries (or ligb* for short) at build time,
> thus it depends on the ABI version of those underlying libg*
> libraries at runtime.
>
> If the proposed patch gets accepted, we will no longer be able to
> support parallel installed bindings for multiple libg* ABI
> versions for a single python version -> ie what happens when we
> get libgtk+-4.0 (and 5.0, etc) and some pyg* application uses API
> from the older libgtk+-3.X version that has been removed from the
> newer version?
Well, not really for gtk+ because gobject-introspection provides its
own way of choosing which version to load:
from gi.repository import Gtk
Gtk.require_version('3.0')
Now, when glib breaks API compatibility, then we would need something
like this for parallel installation, but glib breaking API doesn't
directly mean PyGObject would need to break it...
Regards,
Tomeu
> Many of those applications will not be ported overnight when an
> ABI breaking version of the underlying platform gets released.
> If we look back at the upgrade from gtk-1 to gtk-2, it took some
> projects years(!) to migrate or for them to be replaced (maybe
> not for pygtk projects per se, pygtk was still relatively young
> back then). And what about all those projects where maintenance
> gets stalled (for lack of interest or manpower or whatever reason)
> but remain useful?
>
> This is exactly the problem the pygtk.py module with the gtk-X.X
> directories had been designed to solve. Therefore, it might be
> prudent to keep that system for selecting ABI versions from
> python with a simple "import x; x.require('X.X'). Even if the problem
> it solves is a situation that we encounter only every few years...
>
> I can understand that the current name of the module (pygtk.py)
> and installation directory (gtk-X.X) have been chosen in a time
> where there was only pygtk and some people would like to change
> them now to better reflect the progress that has been made.
> If the names have to change, some proposals could be:
> - pygi.py + gi-X.X (obvious)
> - pyglib.py + glib-X.X (glib being the foundation of the platform)
> - pyg.py + g-X.X (PYthon Gnome, as gi gives us access to most,
> if not all of the GNOME Platform)
> - pygp.py + gp-X.X (PYthon Gnome Platform, same as above but mention
> platform in the acronym)
> - or anything else, really...
>
> Only it should still be possible (actually, it should be required)
> for applications to say "this app has been written against libg* ABI
> version X.X so let met talk to a version of the bindings that's going
> to understand me".
>
> Taking into consideration all of the above, the support matrix might
> look something like this (taking pygi as the module/directory name just
> to illustrate):
> python26/lib/site-packages/
> gtk-2.0
> contains:
> pygtk-2.22.0
> pygobject-2.26.0 (-gi)
> gi-3.0
> contains:
> pygobject-3.xx.x (+gi)
> pygtk.py (selects <=2.0,
> mention pygi.py if >2.0 is requested)
> pygi.py (selects >2.0,
> mention pygtk.py if <=2.0 is requested)
>
> python27/lib/site-packages/
> gtk-2.0
> contains:
> pygtk-2.22.0
> pygobject-2.26.0 (-gi)
> gi-3.0
> contains:
> pygobject-3.xx.x (+gi)
> pygtk.py (selects <=2.0,
> mention pygi.py if >2.0 is requested)
> pygi.py (selects >2.0,
> mention pygtk.py if <=2.0 is requested)
>
> python31/lib/site-packages/
> gi-3.0
> pygobject-3.xx.x (+gi)
> gi-4.0 (somewhere in the future...)
> pygobject-4.xx.x (+gi)
> pygi.py (selects >2.0,
> mention Python2 and pygtk.py if <=2.0 is requested)
>
> Also note that the pygtk.pth file installed by pygobject [3] should
> be removed again for both the 2.0 and 3.0 and future 4.0, etc series
> of pygobject as:
> - adding the correct directory to sys.path is the job of pygtk.py/pygi.py
> - it breaks the case where multiple pygobject versions supporting different
> ABI versions are installed into the same python interpreter version and
> the application does not "require()" a certain ABI version.
>
> If anything gets decided, I'm willing to do the necessary bits for the
> ms windows (setup.py) side of things (immediately for pygobject-2.x,
> when a gtk+-bundle-3.0 gets released and works for pygobject-3.x).
> I don't know nearly enough about autotools to even dare touching
> configure.ac/Makefile.am files though...
>
> Any thoughts?
>
> mvg,
> Dieter
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=621525
> [2] https://bugzilla.gnome.org/attachment.cgi?id=163672
> [3] introduced in Makefile.am when pygobject got split from pygtk in
> commit 551a38178f7e66f215980fb01200472c8e6d3cd4 by Johan Dahlin,
> 2006-01-09 13:26:46.
>
> http://git.gnome.org/browse/pygobject/commit/?id=551a38178f7e66f215980fb01200472c8e6d3cd4
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> python-hackers-list mailing list
> python-hackers-list gnome org
> http://mail.gnome.org/mailman/listinfo/python-hackers-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]