Re: Using python + pygtk in Desktop modules

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-09-28 at 22:44 +0200, Murray Cumming wrote:
> On Tue, 2004-09-28 at 13:26 -0400, Sean Middleditch wrote:
> > I am not talking about the Python app ABI, I'm talking about the C API
> > Python exposes.
> 
> I'm not personally that concerned with cross-distro packages, and I
> don't think they should be a big factor for us yet, but:
> 
> Are you saying that the Python C ABI changes between minor releases? I
> doubt that, so I don't think that's an obstacle to cross-distro packages
> - just link to a specific version of python's C ABI, such as 2.2 or 2.3.
> Surely that's possible?

The modules have to be installed into a minor-version specific dir,
i.e., /usr/lib/python/2.3/site-packages.  And if you try to just copy a
compiled module from 2.2 to 2.3, it might actually work (in both cases
I've tried it did, actually) but Python complains very loudly about it,
indicating that they don't support it.

I also looked up in the Python release notes, and indeed the language
itself *has* changed in the 2.x release series; i.e., apps written for
an older 2.x release may not work in a newer 2.x release.  I don't write
a lot of big Python apps, but I do recall being bitten by such a change
before, in 2.1 I think.  The Python language adds keywords and removes
deprecated features in minor releases.  I.e. a feature might work in 2.1
with no warning, give a warning in 2.2 about deprecation, and be gone in
2.3.  Third party apps shouldn't have to put up with that.

If that isn't API/ABI instability, I don't know what is.  ;-)

If GNOME dictated that a particular version of Python must be used
(i.e., "Any OS that supports the official GNOME Python Binding must make
Python 2.3 available for this purpose.") and if GNOME had a special
method of launching Python ($prefix/bin/gnome-python-2.3) so that apps
can know they are getting the right version, the problem might be
avoidable.  It's still a PITA, though.

I really would feel a lot better with Python only in the Bindings
Release, far out of the Development Release, and with only very strict
guidelines for apps in the Desktop Release.

> 
> I can see that the /usr/local/bin or whatever in the #! is not very
> cross-distro, but surely it wouldn't be too difficult for the python or
> autopackage folks to come up with a better solution for that, even if it
> involves something hacky like using
> #!/usr/autopackage/bin/symlink_to_python-2.3? 

The problem isn't the hard-coding of the path.  You could just
use /usr/bin/env python or something.  It's in the fact that the app
must be distributed such that it locks into one specific Python release,
*especially* if it includes any public libs.

Say GNOME supplies an app like a music player.  The music player is
split into two parts - an internal interace with a public API and an
external interface.  (This is a good design already used by some apps in
GNOME.)  The internal bit gets installed to Python 2.3's site-package
folder.  Now, say the user has both Python 2.4 and Python 2.3.  The
front-end app must make sure it is only launched with 2.3.  Thus is must
hard-code that.

For a third-party application, this is a pain.  This is why Python has
to be kept out of the Developer Release; it just doesn't meet the
guidelines we have for forward and backward compatibility.

For apps included in the GNOME Desktop Release, this is workable.  The
packages can detect which version of Python is currently installed and
make any changes necessary for the package to work.  The only potential
problem then is if the package is meant to be moved around.  If everyone
is of the mind that core GNOME packages are to be OS specific, I guess
that isn't a problem.  When the OS is upgraded, GNOME will likely be
upgraded with it.  The only potential problem is if the app required
some Python 2.2/2.3 feature that's removed in 2.4/2.5, or some new
keyword is added that causes the app to have a syntax error, or
whatever.

Moving an app from an older Python release to a newer release can
*potentially* have the same sorts of problems you'd see trying to
recompile a C app as C++.  Often times it'll Just Work(tm).  For some
particular cases, it won't.
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.