Re: Proposed Modules, My Take

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2005-01-19 at 21:43 +0100, Murray Cumming wrote:
> On Wed, 2005-01-19 at 15:14 -0500, Sean Middleditch wrote:
> >   Two systems both running the same version of
> > GNOME and the same version of PyGTK could have different versions of
> > Python installed.
> 
> Yes, but it's up to the installer/package-management to make sure that
> the correct version is there. If it's not, then the application will not
> even start to run. That has nothing to do with pygtk.

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.

The entire problem is that you're laying the entire problem on the
distribution, making a "compliant" distribution impossible.  An ISV
cannot possibly use PyGTK unless they repackage it for each distro.
That isn't compatible with the ABI guarantees of GNOME, which in all
cases except for PyGTK allow a vendor to ship binaries that work on all
systems running a compatible version of GNOME.

This is really simple - either GNOME specifies a version of Python, or
PyGTK does not provide a stable and guaranteed platform on which ISVs
can build, and thus has absolutely no place being in the Bindings - it
belongs in the Desktop at most, and not even there until GNOME ships
PyGTK-using apps.

PyGTK does not live by itself.  I don't care if PyGTK's ABI is stable.
PyGTK has a VERY strong dependency on the ABI of Python - if Python
changes, so does PyGTK.  By putting PyGTK into the Bindings of GNOME you
are forced to put Python itself there - otherwise you are breaking ABI
rules.  GTK can't be in the Platform without GLIB because GLIB's ABI is
highly exposed through GTK.  The exact same thing is true with PyGTK and
Python - the two go hand in hand, and do not live in separate universes.

> 
> >   Or one system could have two versions of Python, with
> > only one of them having the PyGTK stuff.
> 
> Again, the installer/package-management must ensure that pygtk is
> installed.

But for which version of Python?

I wrote FooApp.  I make it so FooApp uses Python 2.3 because that's what
my development box used.  I ship FooApp.  Someone using Debian has
Python 2.3 left on his machine from a while ago, and Python 2.4 is
installed which most of the rest of the system uses.  My app does not
work on Debian without modification - even though that modification is
hopefully just changing the #! line (although it could be much, much
more).  My app was developed using *only* the interfaces defined by
GNOME 2.10, all of which have a _documented_ guarantee that my app will
work in all GNOME 2.10 and higher installations.

The packaging system has *nothing* to do with this.  FooApp might not
even have been in a package; many apps come in binary tarballs, Loki
Installers, custom installers, maybe Autopackages soon, and so on.

Now take Fedora.  When Fedora pushes Python 2.4, Python 2.3 is gone
entirely.  There is no possible way that RPM depends could fix the
situation.  The only way to fix it is to make sure Python 2.3 is there.
Which is entirely possible if the Fedora developers wanted to do it.

If GNOME states that, for GNOME 2.10, Python 2.3 is required, then
either:
 a) Fedora will make sure this happens, or
 b) Fedora will ignore it, and *Fedora* has broken GNOME

The difference is that if you don't specify the version you are not
specifying a stable ABI at all and PyGTK is breaking it's own rules
because *it has no stable ABI since the ABI it depends on is undefined*.
Fedora has no way to "get it right" since "right" is undefined.

> 
> >   How does an application know
> > which one to pick?  It knows it's developed against GNOME/PyGTK 2.10,
> > and that's it.  If you specify, "GNOME 2.10 shall use Python 2.2," then
> > the application author also knows which version of Python to specify and
> > the app will work on all GNOME 2.10-compliant boxes.
> > 
> > If GNOME does not specify a version of Python than the entire existence
> > of PyGTK in the Bindings becomes quite useless as a developer can't
> > reliably use them.  Why even bother putting PyGTK in Bindings if
> > developers can't rely on their app actually working?  They're still
> > going to rely on individual distros, which is the exact same situation
> > you had before putting PyGTK in Bindings.
> 
> You can't force distros to install python x.y, just because we say that

Yes, you can.  Well, not *force*, but recommend.  The problem is you're
not even doing that.

> it's what GNOME wants them to install, much as I wish that distros cared
> more about offering stable development platforms.

Maybe if you told them what the stable development platform looked like,
they would. ;-)

You really can't complain that distros don't offer a stable platform
when you are at the same time asking that GNOME release modules with
undefined platforms.  ;-)

> 
> Different applications do use different versions of python. I don't
> think there's any way for a non-broken distro to avoid managing those
> dependencies properly.

Look at Debian, it works fine.  Even if 90% of the software in Debian
starts using Python 2.4 (and even PyGTK in Python 2.4) it is still
possible to have Python 2.3 and PyGTK for 2.3 installed.  Even if the
only reason Python 2.3 is kept around is because GNOME 2.10 depends on
it, at least then when the user grabs some ISV application (like FooApp)
from fooapp.com it will install and run as expected.

Fedora and others don't do this currently, but they have no reason to -
nobody is telling them, "You need to keep Python 2.3 around for
compatibility."  If you *do* tell them and they break it it's no worse
than things are now.  It might just happen that you tell them and they
actually listen. ;-)

All you have to do is just document that GNOME 2.10 depends on Python
2.3 for PyGTK.  One sentence will do it.  If distros ignore you then its
no skin off your back.  Just give them the chance to have a clue and
maybe get things right.

That's all I ask.  ^_^  (I just use way too many damned words to ask
it.  ;-)

>