Re: Using python + pygtk in Desktop modules

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-09-28 at 18:13 +0200, Danilo Šegan wrote:
> 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).

Yes, actually, it *is* being done.  Look at the Autopackage project, at
the distro-independent Mozilla or OOo packages/installers, at various
commercial apps that install with loki_setup or some other installer,
and so on.

The stable C ABI *is* used, and works great.  And it works because of a
"pipe dream" that people actually worked on, instead of taking your
approach and going, "oh, things aren't perfect right now, so forget
trying to make it better." (yes, that was over-dramatized - no offense
meant, Murray.)

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

GCC3 did indeed break a lot of things.  It's not an excuse to keep
breaking things left and right.  It's an example of how making decisions
purely for technical reasons with no thought to how much you screw over
users can make the system a nightmare to use.  GNU/Linux systems aren't
marketed to anyone but geeks and niche corporate markets, so it is still
OK to pull crap like that.  If the systems were on even 10% of the
desktop market, you'd destroy the system's credibility by breaking most
of the applications in existence.  There are still tons and tons of
companies and individuals that won't touch GNU/Linux specifically
because of all the turmoil, and the fact that their proprietary or in-
house apps can't live in an environment like that without massive
support costs.

It's a reason I'd argue against using C++ for any Developer Platform
modules, too, at least until a stable C++ ABI is out and around for a
few years.  (LSB 2.0 seems like it might take care of that, finally, in
a couple years when it's widely available.  The GCC developers are also
claiming, again, that the new v6 C++ ABI is final...)  

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

I am not talking about the Python app ABI, I'm talking about the C API
Python exposes.

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

Freetype2 also provides a stable ABI.  I can upgrade to a newer release
of Freetype2 and things don't break.  With an upgrade of Python, either
all of my apps have to have the old version hard-coded in, or all of my
libraries (including any libraries distributed with the app) must be
upgraded.

A 100% pure Python app that installs all .py files to /usr/lib/app
or /usr/share/app and depends only on core Python libraries and pygtk
will work fine during an upgrade, in *most* circumstances.  (I recall
having to modify some Python code for altered API during the early
2.0/2.1 releases - something with sockets, iirc.)

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

Actually, people complain left and right about Mozilla, and many
developers are still waiting for the API/ABI stable GRE.  You'll also
note that Mozilla is not part of the Developer Platform; we don't tell
third-party app developers to use Mozilla, because we know it's
unstable.

> 
> Cheers,
> Danilo
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.