Re: Using python + pygtk in Desktop modules
- From: Sander Vesik <sander_traveling yahoo co uk>
- To: Sean Middleditch <elanthis awesomeplay com>, desktop-devel-list gnome org
- Cc:
- Subject: Re: Using python + pygtk in Desktop modules
- Date: Fri, 1 Oct 2004 16:34:32 +0100 (BST)
--- Sean Middleditch <elanthis awesomeplay com> wrote:
> 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.
>
And getting there is actually really simple - you just fix the build
machine at a pre-agreed library levels and you "suddenly" get binaries
that "just work" for everybody. Sure, this can't be the same box you
experiment with your pet latest unstable glibc and X.org / Xfree86 on,
but its not a large problem.
There are people out there making glibc 2.0.x compiled versions of OOo.
> 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...)
>
The gcc c++ abi instablity is a *MAJOR* PITA. It would be very nice to have
c++ bindings in the platform, but as things stand it just doesn't make sense.
Having a platform component that regularily breaks on all supported platforms
except Solaris would be ... quite bizzare, honestly.
> --
> Sean Middleditch <elanthis awesomeplay com>
> AwesomePlay Productions, Inc.
=====
Open Source - the religion of doing it right
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]