Re: multiple vala versions in 3.4

[Evan Nemerson <evan coeus-group com>]

On Mon, 2012-01-23 at 17:12 +0200, Zeeshan Ali (Khattak) wrote:
> On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi <ebassi gmail com> wrote:
> > hi Zeeshan;
> 
> Hi Emmanuele,
> 
> > On 23 January 2012 02:14, Zeeshan Ali (Khattak) <zeeshanak gnome org> wrote:
> >> On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau <teuf gnome org> wrote:
> >>> 2012/1/21 Zeeshan Ali (Khattak) <zeeshanak gnome org>:
> >
> >>>> There are way
> >>>> too many of the libraries to take care of and on top of that they
> >>>> change all the time. Ideally each library should be providing vala
> >>>> bindings and take care of keeping it up2date. So its really not a
> >>>> fault of vala itself.
> >
> > I don't agree with this assessment.
> >
> > you're just deferring the issue to every library under the sun, and
> > this is very much problematic in a variety of reasons:
> >
> > - as a maintainer, now I'd have to care not only about introspection,
> > but also about a vapi file - which is another redundant format that
> > expresses the library's API; so the first thing I'd look at would be
> > generating the latter in terms of the former, which introduces a build
> > dependency (albeit optional) on Vala. so it's my library that now has
> > to deal with the compiler and generator bugs. yeah, right: not going
> > to happen.
> 
> What I was proposing wasn't so different from what you are saying
> here. Vala bindings should still be generated out of gir bindings but
> since gir doesn't support some of the essential features that vala
> apps have been depending on for some time now, we'll need to have
> *some* vala-specific metadata, at least until gir supports those
> features.

I've been putting together a guide for people wanting to maintain
bindings upstream, and it includes an incomplete list of discrepancies
between GIR and Vala (and how to work around them):
https://live.gnome.org/Vala/UpstreamGuide#Using_Metadata_Files

> If having any vala-specific metadata in a few libraries isn't
> acceptable to maintainers, yeah we should first separate out the
> bindings into another package and then push the bindings that are
> purely generated from gir to their respective libraries.

I think it's worth pointing out here that most libraries aren't going to
have a lot of metadata. Clutter's API is pretty large (the vapi is 7283
lines) and it only has 158 lines (including comments and whitespace,
less once bug #667840 is resolved) of metadata, but most libraries will
only have a few lines.

> BTW just for the record, It should be noted that gir is the cause of
> the problem here not vala.

That's not really fair. It's true that there is some stuff that GIR
doesn't support that we would like them to, but Vala's GIR parser has
bugs too. Up until fairly recently Vala's GIR parser was definitely the
bigger problem.

> > - I have used Vala, but I'm not an expert on figuring out its quirks,
> > nor am I using it for my day to day work; this means that I'll have to
> > rely on Vala developers to update the Vala bindings. this means that
> > Vala developers and users will now need to go through various bugzilla
> > products and git repositories to fix the Vala bindings in each and
> > every project that ships one.
>
> They'll have to go through the same procedures as python and
> javascript users so I don't think this is an issue. Actually this will
> give good motivation to vala developers to fix/improve your gir
> annotations for you.

Yes! After the initial work to get bindings working properly, most of
the stuff we do is actually fixing things in the metadata file that
could/should really be fixed in annotations within the upstream project.
This means that currently my workflow often looks something like this:

     1. Tweak the metadata to fix the issue in the vala repository and
        regenerate the bindings.
     2. Create a patch against the upstream library to resolve the issue
        with annotations.
     3. File a bug report with the patch and wait for upstream to
        resolve the issue. Example: clutter bug #667840
     4. Undo the changes to the metadata file in the vala repository and
        instead regenerate the bindings using the updated GIR.

My offer to help with maintenance for libraries wanting to move bindings
upstream wasn't entirely selfless; I could eliminate steps 1 and 4. It
also means that you get those annotation fixes sooner rather than later
(sometimes much later since I sometimes don't get around to #2 for a
while, and sometimes someone else does #1 doesn't worry about the rest),
which fixes the GIR-based bindings for other languages as well.

The other obvious advantage is that users don't have to wait for a new
Vala release to get updated bindings.

Finally, we can stop worrying about a whole class of issues where the
bindings are too new. Say a library has a virtual function and they
decide they want to add a method which invokes it (a pretty common
scenario). After you regenerate the Vala bindings valac will start using
the invoker automatically instead of calling the vfunc directly, which
works great for the latest version of the library, but breaks for people
running an older version. If Vala bindings are distributed with your
library the API will match the library on that system.

Another example is gdk_pixbuf_get_pixels_with_length, which could
replace Gdk.Pixbuf.get_pixels in the Vala API transparently but for the
fact that it doesn't work on older versions of GdkPixbuf. Therefore, we
now have a slightly broken get_pixels method for backwards compatibility
and a much less nicely named get_pixels_with_length method which is what
people should really be using. If the vapi were tied to the installed
version this wouldn't be a problem.


-Evan