Re: What is the significance of pygtk.require('2.0')?

[Robert Park <rbpark exolucere ca>]

On Fri, Oct 29, 2010 at 1:12 AM, John Palmieri <johnp redhat com> wrote:
> It is really hard to support Gtk 2 in GI since there is a lot of arbitrary C code that can't be wrapped.  We aren't dropping Gtk 2 per se.  The plan is to keep PyGtk working for Gtk 2 and have PyGI focus on Gtk 3.  You can sort of use it for Gtk 2 but things like style structures will not work and there is just a lot of API that isn't annotated correctly.  Here is the support matrix:
>
> Gtk2 -> Python 2 -> PyGTK (maintenance mode mostly)
> Gtk3 -> Python 3 -> PyGI (though Python 2 support has been easy to maintain and I'm really the only person developing on Python 3 as of now)

So I've already gone through the pygtk->pygi porting pain, how painful
is gtk2->gtk3, or for that matter python2->python3 going to be?

>> > As for you needing to add them to new code, I don't think it is
>> necessary though it may be on some systems.
>>
>> Ok, so I can safely remove that from my program? It's only for legacy
>> code?
>
> I can give you a big equivocal "I'm not sure".  My whole writeup was just working out what could go wrong and why we haven't gotten rid of it.  It really is a bunch of voodoo we inherited and I would like to remove it, but only if I am 100% sure we will not break apps.  To tell you the truth I never actually imported them though I do notice that sometimes when I am installing to alternate directories for testing, things go wrong.  My advice is you can remove it but keep in mind, if someone complains they can't run your app that might be the cause.

Ok. As soon as my app gets it's first user, I'll let you know ;-)

>> I don't personally care what path pygi is installed to. My question
>> is, what specific purpose does "pygtk.require('2.0')" serve when the
>> pygtk module is not ever referenced afterwards? Can I safely remove
>> this from my program without breaking anything?
>
> Ignore the fact that the module is called pygtk.  That is just an effect of the directory it is installed into.  The code mostly just sets a few global variables that other code then references (and also sets up paths).  I'll have to look at it in depth.

OooooooooOOOOOOOOOOOOOOoooooooooooooooooooooooh. NOW I understand why
everybody started obsessing over paths when I asked about the module
name.

>> From my casual understanding, it seems to me that I'm importing the
>> old static bindings, telling them to require some version of
>> something
>> or other, and then never using them in favor of using the
>> introspection bindings afterwards. I guess the root of the issue here
>> is that I am very confused about the meanings of the terms "pygtk",
>> "pygi", and "pygobject" and how they relate. I _thought_ that "pygtk"
>> meant "old, static bindings, crufty, unsupported, don't use anymore"
>> and "pygi/pygobject" meant "new, introspection, sexy, dynamic, the
>> future", so I'm just not sure why I am importing the pygtk module
>> _at_all_ when I am only using introspection bindings. What purpose
>> does "pygtk" module serve in introspection-land?
>
>
> A little more background.  Static bindings and the introspection bindings both work off the same pygobject base.  The pygtk "module" is part of that base.  It is an effect of the directory everything is installed into.  At one point there was no pygobject, only PyGtk which is why the module is named pygtk.  GObject started to be used for a lot more non-gui stuff so it was decided to split the Gtk code from the GLib/GObject code.  The directory pygtk was kept the same for pretty much the same reasons we can't come to a decision now.  It might break things ;)  So when you import pygtk you aren't actually importing anything Gtk.  You are setting up a few variables.  Either way it doesn't hurt, it just look ugly and is somewhat confusing.  But like I said, try not importing it and let us know if anyone complains.

I see now, thanks. So the debate going on is then something along the
lines of "we should change the installation path so that the module
name makes sense, but we don't want to break anything for anybody
else"

Seems to me a couple symlinks would fix this up real nice, but I won't
pretend to know better than you guys ;-)

-- 
http://exolucere.ca