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

["Dieter Verfaillie" <dieterv optionexplicit be>]

Quoting "Tomeu Vizoso" <tomeu sugarlabs org>:
> > * Where are the following going to be installed?
> >    * tests and testhelper?
>
> Do we really need to install those?

On mswindows they are (well, will be with the next stable release
anyway) installed into site-packages/gtk-2.0/tests/pygobject. The
pygtk package installs its test into site-packages/gtk-2.0/tests/pygtk.
At least this makes it somewhat manageable to run the test against
various python, gtk+ and windows versions...

If the installation of the tests is a windows-only thing, it doesn't
matter if gtk-2.0 goes away or not, setup.py can be adapted :)

> >    * 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?
> No idea myself.

I've done some further research on dsextras and I'm pretty sure now it's
only used to support building static bindings packages with distutils (which
is a windows only thing since commit 6d7a3ab9ce352692d0faccbf106974d264fa953d
by John Stowers, 2010-04-15 12:49:17). The comment in dsextras.py alone is a
dead giveway: # dsextras.py - Extra classes and utilities for distutils...

As such it should probably be treated like codegen and stay in gtk-2.0 for
as long as static bindings are supported. When we get rid of the static
bindings, there's no longer any use to install it, but it should be kept
in the source distribution of pygobject next to it's setup.py so we can
still build pygobject on windows.

> > * 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?

Hmmm. Did some further research and found some gems in the pygtk faq
(2.4 and 2.6). Breaking a supported feature (what the faq calls 'default
pygtk version') would indeed be a bad idea.

Going over this again I think there might be a better solution though:
the moment pygobject is changed so the gi, gobject and glib modules no
longer install into gtk-2.0 as John Palmieri suggested, me move the
.pth file back to the pygtk project.

The result looks like this if you install pygobject:
  * but you don't have the static pygtk package installed:
      > gtk-2.0 is not placed on sys.path on interpreter startup as
        there is no .pth file to read. Good riddance...
  * you have the static pygtk package installed:
      > the .pth file is read on interpreter startup, nothing changes
        compared to how it used to be and everything keeps on working
        as it is today...

The only thing left to consider in this case would be if the
pygtk.py file itself gets moved together with pygtk.pth.

> >  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.

It's not up to me to decide anything, but is a kludge like that really
planned to be supported? Maybe I missed the point of the whole gi effort,
I thought the goal was that static bindings will be abandoned in favor  
of introspection... Looks like I have some more reading to do ;)

mvg,
Dieter


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.