Re: pygobject matching glib version numbers
- From: John Stowers <john stowers lists gmail com>
- To: Simon van der Linden <svdlinden gnome org>
- Cc: release-team gnome org, python-hackers-list <python-hackers-list gnome org>, pygtk <pygtk daa com au>, Tomeu Vizoso <tomeu vizoso collabora co uk>
- Subject: Re: pygobject matching glib version numbers
- Date: Wed, 11 Aug 2010 22:04:44 +1200
On Wed, 2010-08-11 at 11:44 +0200, Simon van der Linden wrote:
> On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote:
> > On Wed, Aug 11, 2010 at 10:57, Simon van der Linden <svdlinden gnome org> wrote:
> > > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote:
> > >> The rationale is that it will help people a bit to know what to expect
> > >> from a given PyGObject release. He's already numbering his PyGtk
> > >> releases matching Gtk+ versions.
> > >
> > > I wonder whether it makes sense for PyGObject, which is not, to my
> > > knowledge, a set of static binding for GLib. We don't exactly ensure
> > > that all the features available in the matching GLib version is
> > > available to Python developers, do we?
> >
> > I think that's something we should aim for. I also consider g-i to be
> > a logical part of GLib even if it hasn't been merged yet.
>
> I'm neither in favor nor against this change. I think it will not bring
> anything.
I have lost track of the number of times I have had to explain the
versions of Gtk, PyGtk, Glib and PyGObject to people trying to get stuff
to work on windows, and every time noted that the version mismatches
were unhelpful, confusing and often resulted in them trying
build/runtime combinations that did not work.
This is less the case on linux where your distribution/package manager
hides it from you.
John
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]