Re: Using python + pygtk in Desktop modules

[Murray Cumming <murrayc murrayc com>]

On Tue, 2004-09-28 at 15:23 -0400, Sean Middleditch wrote:
> 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 think you're saying that 2.3.2 might break apps that previously used
2.3.1. Even if it's happened by accident in the past, I'd be very
surprised if this is policy.

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

But in python versioning, those are major versions, and, like you say,
you can install them in parallel.

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

As long as it doesn't break an App that chooses to use a particular
branch of the ABI, then I think it's ABI-stable as far as we are
concerned . We don't demand API stagnation, but we do demand that apps
don't break.

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

Yes, it seems necessary to specify a python version. But it only seems
necessary to have a cross-distro way to do it if you're making cross-
distro packages, so I'm happy to leave that to people like the
autopackage folks.
 
> I really would feel a lot better with Python only in the Bindings
> Release, far out of the Development Release, 

I think you mean Platform release, but it wouldn't make much difference.
Both the Platform and the Bindings are GNOME development platforms. The
Bindings are not less official or less supported, though neither words
mean have exact meanings.

> and with only very strict
> guidelines for apps in the Desktop Release.

Yes, I think apps should use a specific version of the Python API/ABI.

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

Please see above for my hacky way that autopackage could provide a way
for autopackage packages to launch with 2.3. You have to actually
specify a version if you want to specify a version.

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

You don't seem to be justifying that statement. But again, the Bindings
make just as much of a fuss about API and ABI stability as the Platform.
It's not a dumping ground for stuff that breaks applications. I've put
the Bindings maintainers through interrogations such as this one to make
sure of that.

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

I don't like that solution, because it requires all packages to be
updated, and it prevents 2 apps using 2 versions of python from
coexisting.

[snip]
> 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.

Again, you need to give a specific example, and not of something that we
would not be stupid enough to do.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com