Re: What is the significance of pygtk.require('2.0')?

[Tomeu Vizoso <tomeu vizoso collabora co uk>]

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
>