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.
_______________________________________________
pygtk mailing list   [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Reply via email to