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

["Dieter Verfaillie" <dieterv optionexplicit be>]

Quoting "John Palmieri" <johnp 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.