PyGObject directory issue again, taking a stand

[John Palmieri <johnp redhat com>]

Hi all,

I'm taking a stand on the issue of PyGObject modules being placed in the gtk-2.0 directory.  This causes path issues when built in a buildroot and causes confusion issues when developers aren't sure if they should import pygtk and call pygtk.require('2.0').  Not to mention that PyGObject Introspection targets Gtk-3.0.

My proposal, which I am going through with if there is no serious objections, is this - move the gi, gobject and glib modules outside of the gtk-2.0 module into the site-packages top level module directory in the next unstable release.  If it breaks the world we can move back before distros ship with it.  All static generated bindings will keep on keeping on inside the gtk-2.0 directory.  Because of how search paths were setup this should really not produce any visible changes in apps but will allow us to drop the requirement to import pygtk for next generation apps.  The only issue I can forsee is if static generated bindings were using relative imports.

Should we need to have a parallel installable glib/gobject 3, we can simply namespace them as glib3 and gobject3 when the time comes.

If you feel this is a really bad idea, speak now.   
 
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.