Re: pygobject matching glib version numbers

[will kahn-greene <willg bluesock org>]

On 08/11/2010 06:04 AM, John Stowers wrote:
> 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.

I'm not on most of the cc:d lists, so this might bounce.

I have this exact problem.  I try a bunch of build/runtime combinations
until I find one that works.

Even if the version number scheme doesn't change so that things match,
there should at least be a table somewhere that tells you which version
of the bindings goes with which version of the bound library.

If such a thing already exists for PyGtk and PyGObject, I'd love to know
where it is.

/will