Re: ANNOUNCE: pygtk-1.99.8

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

- 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.


(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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]