Re: ANNOUNCE: pygtk-1.99.8

[James Henstridge <james daa com au>]

Thomas Leonard wrote:

> James Henstridge <james daa com au> wrote:
>
> > I have uploaded a pygtk-1.99.8 tarball, which will work with the 2.0 
> > release of gtk+.  It is still not quite release quality, but it is 
> > getting there.
>
> Very nice. I like the interface much better than the 1.2 one. However, I'm
> still worried about backwards compatibility. I have quite a lot of pygtk
> 1.2 programs (sketch, pythontheater, pysol, etc), and I've written many of
> my own which are now installed on other people's computers.
I have explained this to you before.  The difference between the C and 
Python is that the names of modules are part of the API.  Changing a 
module name means doing many changes to many pieces of source code. 
There are a number of ways to parallel install the two versions of pygtk:

  1. install the two pygtk's to separate directories, and set the
     PYTHONPATH environment variable to a suitable value.  Most
     substantial python programs already use a shell script to
     bootstrap, which sets PYTHONPATH to give access to the rest of the
     modules in the app.  Adding an extra directory is not a big deal.
  2. If you have multiple versions of python on the system, you might
     decide to install different pygtk versions on each (you won't be
     able to install new pygtk on any pythons < 2.2, for instance).

Having a standard "alternative location" would help out apps wanting to 
use old pygtk in scenario (1).  That would be useful for a future 
release on the stable branch.  I can add --with-pythondir and 
--with-pyexecdir configure arguments to both 1.2 and 2.0 branches which 
should help with this.

> I'm hoping that when people install the 2.0 bindings, these old programs
> can continue working, in the same way that C programs can. However, the
> new bindings use the same module name ('gtk'), so I don't see how this can
> work (the two are incompatible).
>
> Eg, this program:
>
> 	import gtk
> 	w = gtk.GtkWindow()
> 	...
> 	
> is correct if the 1.2 bindings are installed, but incorrect once 2.0 is
> installed. Whereas, this:
>
> 	import gtk
> 	w = gtk.Window()
> 	...
>
> is correct if the 2.0 version is installed, but not if 1.2 is being used!
People have been asking for this change for years.  The switch to 2.0 
gave an opportunity to fix many of the problems with pygtk's 
infrastructure.  The new codebase is much more maintainable, and 
hopefully nicer to use.

> This leaves us (the ROX project) with several possibilities (none of which
> I really like):
>
> - Stay with 1.2 for a year or so. This means we don't get the nice new 2.0
>  look or any of the new features. After a while, people will start
>  complaining because they've upgraded and can't run our programs any
>  more.
>
> - Move to 2.0. However, we can't really ask people to install the 2.0
>  bindings, since that will break all their old programs. So, noone will
>  be able to use the programs for a long time.
>
> - Make our own distribution of pygtk using the module name 'gtk2', and
>  write our programs to use that. This is good in the short term, but it
>  means more installing work for users who have also installed the
>  official package.
Or install pygtk in a private directory, along with the rest of the 
modules in your program.  Use a shell script to launch your program, and 
set PYTHONPATH appropriately.

> - Switch to C or another language binding and recommend users stick with
>  the 1.2 python bindings. This is the cleanest approach, but I rather
>  like python and it would be a shame to lose it.
>
> Also, both of the first two options leave us open to everything breaking
> again when 3.0 comes out.
I doubt the changes to pygtk will be as drastic when we move over to 3.0 
(whenever that happens).  I am a lot happier with the new codebase, and 
think it will adapt well in the future.

> How are the other bindings authors dealing with this? Also, what are
> packagers planning to do? I can't imagine Debian is going to allow an
> incompatible upgrade, for example?
Please come up with some new suggestions w.r.t. parallel install issue. 
I have given you reasons why I won't change the module name, and given 
several options about how parallel installs may be done, but you seem be 
ignoring them.

James.

(who wonders what people would have thought if they were told to run sed 
's/Gtk/Gtk2/g;s/gtk/gtk2/g' on their C programs to upgrade to gtk 2.0)

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/