Ok, I took the plunge. I still have not moved the header files since they are mostly used by static bindings and I have not removed the pygtk.pth file. Please make sure to clean out your install and build roots and test against PyGtk and other static bindings to make sure I didn't just break the world.
----- "John Palmieri" <[email protected]> wrote: > 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/ -- -- 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/
