Re: Using python + pygtk in Desktop modules

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2004-09-29 at 01:02 +0200, Murray Cumming wrote:
> On Tue, 2004-09-28 at 16:27 -0400, Sean Middleditch wrote:
> > Here's a list of language-level incompatibilities for 2.1 to 2.2.
> > http://www.sourcekeg.co.uk/www.python.org/2.2.3/bugs.html
> 
> Python 2.2 -> Python 2.3 is equivalent to GTK+ 1.2 -> GTK+
> 2.0/2.2/2.4/2.6. They install in parallel. It's not a problem.
> 
> Are you just complaining that Python makes these "major" parallel-
> installable ABI changes more often, or are you objecting to their
> version numbering scheme being different to GNOME's.

More that they aren't synced with GNOME.  You have GNOME 2.x, but then
it's either running with Python 2.2, or maybe 2.3, or maybe 2.4.  You
can't target GNOME 2.x as a developer, you have to target GNOME 2.x +
Python 2.y.

Say I want to develop an app.  I develop it against GNOME 2.2 and
distribute some packages/installers.  I only need to target different
base platforms.  Now add Python.  Now you've just multiplied the number
of different platforms by several times.  Let's pretend Mozilla was made
part of the Platform.  Whoosh, big huge increase in target platforms.

I'd be forced to distribute my app as source to users, or somehow manage
to build a bazillion different packages.  Pretty much the only way a
normal user could ever hope to get the app then is if it came installed
on their OS.

And yes, I realize that currently there are already a number of
variables, like architecture, kernel, libc, gcc, etc.  I'd like to hope
that glibc and gcc will stop being variables soon (i.e., stop breaking
ABI), and that all a package has to target is "x86-Linux GNOME-2.2".
If, as I suggested before, GNOME mandated a particular version of Python
be used with the bindings, then Python app packages could just target
"GNOME 2.2" and nothing more.  Incredibly simple for the third party
developers and no hassle at all for the users.

> 
> Re. the frequency of major ABI jumps (such as GTK+ 1.2 to GTK+ 2.0): the
> Platform Bindings are not expected to do this only when the C libraries
> do it, because that's not appropriate for all languages - for instance,
> it was impossible to keep ABI in gtkmm when we wrapped new stuff in GTK+
> 2.4, so we did a new parallel-installable version. Obviously that
> introduces some small difficulties for developers who want to use newer
> versions as easily as possible, but it's not that big a deal, and it
> doesn't break applications if the developer does nothing.

> 
> Here are the Platform Bindings rules, if you are interested:
> http://developer.gnome.org/dotplan/bindings/rules.html

The problem I see is if distros don't *also* always include the older
releases of the bindings, third party apps, while they may not break on
an upgrade, may not be installable on newer distributions, because the
bindings aren't available.

Say I develop an app for GNOME 2.4 and gtkmm 2.4.  It installs and works
fine on today's machines.  Now, a year down the road, a user has Fedora
Core 5 installed with GNOME 2.12 and gtkmm 2.12.  They try to install my
app, but it doesn't work, because there is no gtkmm 2.4 package for FC5.
If my app were developed against the C bindings, it would work fine
(assuming the glibc/gcc people didn't decide to screw users again).

Perhaps if the Bindings release stated that officially the older
release's modules were included, it would become reliable.  Third party
developers will know for sure then that a machine with a future 2.x
version of GNOME will still be able to install and run their apps
developed against 2.4/2.6/2.8, etc.

I guess I would also feel a lot better if the documentation for the
Bindings made notices about these ABI problems very, very prominent.
That way, developers won't target one of the bindings only to find out
down the road that they will forever after be forced to release updated
packages.

I'm not sure there's a whole lot of room left in this debate.  This
seems less an issue of fact vs fact and more one of opinion vs opinion;
I value ABI stability above _almost_ anything else when it comes to a
development platform.

>