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

["Dieter Verfaillie" <dieterv optionexplicit be>]

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?

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.