Re: Proposed Modules, My Take

[danilo gnome org (Danilo Šegan)]

Hi Sean,

Yesterday at 22:29, Sean Middleditch wrote:

> No, but it has to do with PyGTK being an officially supported binding
> for GNOME, which claims to offer a stable ABI for which third-party
> software developers can ship applications and expect them to run on
> compliant distributions.

How do we treat a case of a system where Gnome runs perfectly, but
libc is lacking in some ways.  So, there's a Gnome application which
makes use of a libc function which doesn't work as expected on the
system, or doesn't work at all. (ok, this is more of an API issue,
instead of ABI issue, but it's still very much similar in my opinion)

Is this really Gnome's fault?  Should we not support such system at
all?

Python in PyGTK case is equivalent of libc on Unix platform case.  You
can have two libc's compiled on your system, and you'd have to go to
extra length to make your application work on the one which is not the
default.  That's perfectly reasonable, IMO.

While Python ABI may break, it really is up to the distributor to
ensure that you're calling proper Python which has PyGTK available.
This is very simple to justify.

Does our C source code actually run anywhere?  

No, you need to compile it, or get yourself a binary package.  If it's
a binary package, they're often limited to certain systems and have
their own system of dependencies, so we need not worry about it.  If
you're "compiling" it, we need to ensure that it picks up the proper
Python version and check for PyGtk.

The area you're most troubled with is most likely fetching PyGtk-using
program in a binary package, and putting it on an incompatible system.
I.e. let's assume our Python program is independent of the
architecture, so you want to install SuperStuff-1.0-fedora.rpm on your 
Solaris.  This can actually work, but then we can make different
requirements instead of mandating specific Python version for Gnome
apps.

For instance, I'd put out the following requirement, for the sake of
Gnome:
- first "python" executable in the $PATH will be used by Gnome
  programs, and it's up to the distribution to ensure that there's
  appropriately installed PyGtk version for it
- PyGTK developers ensure that none of it's own interfaces changes
  semantics, so these calls always stay the same
- It's up to application developer to ensure compatibility across
  different Python versions for any of the Python features outside
  PyGTK

The third point is what you most likely don't agree with.  But it's up
to application programmer to ensure that his C program compiles across
different architectures and operating systems as well.  Most
frequently used Python's internals don't really change that often, and
that's why people generally have little problems running same
applications with different versions of Python.

Other approach would be for us to get in touch with Python crew, and
ask them to stabilise certain language features, and certain part of
the standard library (they can probably tell us better what will be
stable, and what won't), so we'd replace the third requirement above
with:
- For use with Gnome, we guarantee the stability of only the following
  Python features and standard library classes:
   ... and then we list them ...


Mandating specific Python version would be the same as mandating
specific libc and GCC version.  We leave the ABI/API compatibility
problems on those levels to them, we concern ourselves with where we
can help.  If majority of users chooses certain version of Python for
the sake of ABI stability (just like majority of users chooses LSB for
the sake of base system ABI stability), we won't mind at all.

Unless, we want to introduce complete Python in our release set :)

Just my 2c ;)

Cheers,
Danilo