Re: Using python + pygtk in Desktop modules

[danilo gnome org (Danilo Šegan)]

Hi Sean,

Today at 16:50, Sean Middleditch wrote:

> And it's not just packages, it's any app.  GNOME is great for third-
> party developers because they can just push out their app in a (mostly)
> LSB RPM or a tarball or automatic installer or Autopackage or whatever,
> and have it Just Work(tm), because the GNOME ABI is stable and you know
> for sure that any distro with the version you targeted or higher can run
> the app.  This makes third-party packages for GNOME apps actually
> feasible without needing a massive compile farm or expecting users to
> compile from source.

The current practice is *still* to have suitable packages for each
architecture, distribution, and distribution release.  So, you're
basically talking about a pipe-dream, and trying to convince us that
it's not possible with Python (while in practice, it's not being done
even with stable GNOME C libraries).

I have always had more problems running applications distributed via
binary packages for [not-my-system] unless they were, of course,
statically compiled (but ABI is not too important then), than running
Python code written for certain version of Python.  So basically,
Python programs tend to be more cross-architecture (note this one,
which you silently ignore ;-), cross-distribution and cross-release
than binary packages of C libraries/programs.  I'm talking about
completely *real* and *practical* issues now, and I'm not making
things up.  If I don't have suitable GCC 3.x libraries, none of the
GCC3 compiled programs will work for me (I remember something like
this happening to me, but I'm not sure about technical details).  If
that ain't distribution *and* release dependent, I don't know what is. 

I think you're skewing a picture a bit, because both approaches
win you something, and lose something in terms of goals as you
state them (one package for multiple OS releases).

> Honestly, if you expect all apps to be repackaged like this, why are we
> wasting time on ABI stability for _any_ GNOME module?  It buys us
> *nothing* in that case.  Say GTK 2.6 is incompatible with GTK 2.4; if
> you are forced to repackage for every release of every distro, who
> cares?  You don't target GTK 2.4's ABI, you target an OS's ABI, and the
> ABI of whichever libraries that OS has.  FC3 has a different GTK than
> FC2?  Who cares if GTK maintains a stable ABI, you're supposed to
> recompile the app for each OS release anyhow - right?

With PyGTK, API==ABI, and it will stay stable.  Replacing Gtk+ 2.4
with Gtk+ 2.6 would then also mean changing PyGTK, but Python would
stay the same.  3rd party distributor wouldn't ship PyGTK, but would
only ship an app which should work on a *correctly-setup* system.

If we're upgrading Python itself, we're replacing a dependency of
Gnome.  It's same as eg. changing freetype2 library: it's up to the
package to provide insurances that everything it may affect will work
properly after upgrade (and freetype2 has been known to cause
problems, if I remember correctly).  When people use Gtk+, we're not
making any promises on freetype2 library, but only on Gtk+ ABI.
It may cause a mess if freetype2 is upgraded incorrectly (like Python
being upgraded incorrectly) even though Gtk+ is not to blame.

Perhaps freetype2 library is not a good example, but I'm certain
there're some that have changed ABI's during Gnome 2.x release cycles
(probably mozilla gtk embedding), yet nobody made such fuss about
it.  And look, simply installing a recent version of Mozilla is quite
a good way to bork your Gnome setup (at least with some revisions). 

Cheers,
Danilo