Re: Using python + pygtk in Desktop modules (was Re: Revisitingthe Gnome Bindings)

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-09-28 at 11:32 +0100, Gustavo J. A. M. Carneiro wrote:

>   It's like upgrading your kernel without recompiling your 3rd party
> WLAN driver module.  Your WLAN card will stop working until you
> recompile the driver with the new kernel.  People hardly notice this
> because the linux kernel also comes with "batteries included", so almost
> all drivers already come with the kernel.

The kernel does *not* come with "batteries included" for a lot of very
common hardware out there, and even when it does, you are often required
to upgrade kernels or compile things yourself to get those drivers,
which most users have no knowledge of or will to obtain that knowledge.
In a most cases both corporate and personal I've seen, users would then
just use a "better" OS.

If things don't Just Work(tm), people will have every incentive to go
use another platform where things *do* work.  I know from pure
experience not a single friend, family member, or co-worker of mine
shares in my knowledge of hackery - they think the cost of installing
Windows or OS X is perfectly worth it, because to them, they're paying
for the convenience and Just Works(tm) factor.  Not being coders, they
couldn't give a damn about Freedom of code - they just want their
expensive tool (the computer) to work, and work *now*.

If (parts of) GNOME breaks when the OS is updated, then GNOME is a
platform they'd *pay* to stop using.  I doubt any network administrators
really look forward to the hassle, either.

Depending on Python at this point for any core GNOME module would be
disastrous, IMO.  Allowing pygtk/pygnome in the Bindings release
wouldn't be bad; all the GTK apps I've written are in Python, it's a
great language and pygtk is a great binding.  I've also already twice
been bitten by python version upgrades over the last year or two, so I
know first hand what a PITA it is, especially when you rely on a third-
party module.

Also note that many complex Python apps install various libs into the
versioned Python site-packages folder, causing the app to break, even
when all external libs it depends on are included with Python.  This may
be bad practice on the case of app, but it's how things are done right
now.

A lot of apps also hard-code the Python version into their execution
line (#!/usr/bin/python2.2 and so on), which aside from being
distribution dependent, also means you are forced to keep the old python
and old libs installed.

No packaging system that I am aware of handles situations like Python's
(or the kernels, or GStreamer's, or any other framework's) either.
Namely, say you have the framework package of a particular version
installed; python-2.3.  And then you have a versioned library installed
for this framework; say, pygtk-2.3-2.4.  (pygtk 2.4 for python 2.3)  Now
an upgrade of python comes along to 2.4.  The system should see that to
install python 2.4, you need the matching pygtk-2.4-2.4 package in order
to make sure all apps keep working.  No packaging system can do this,
however.  Just like pretty much every packaging system will let you
upgrade your kernel without requiring you to upgrade any drivers you
have installed, potentially going so far as to cause the new kernel to
not even boot.

Python just can't be relied on in its current form to provide the kind
of *long-term* stability that many third-party developers rely on.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.