[pygtk] PyGObject directory issue again, taking a stand

[Dieter Verfaillie]

Quoting "John Palmieri" <johnp at 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?
     * codegen/
         I suppose this one can stay in site-packages/gtk-2.0
         for as long as the static bindings are maintained?
     * 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.

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

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

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.