Monday, May 17, 2010

Ubuntu and GObject introspection

Canonical invited me to spend last week in Brussels at the Ubuntu Developer Summit, representing the upstream projects I'm part of: Telepathy, GNOME and Sugar.

On the GNOME front, I tried to understand Ubuntu plans regarding introspection and developing with Python. At the beginning I was very concerned because the developers I talked to didn't seemed to be aware of the changes that introspection would bring to GNOME and thus hadn't any strategy in place.

The most notable effect of the appearance of introspection support in GNOME is that the existing static bindings for Python and other languages will stop being maintained and no new bindings will be developed for new APIs. For downstreams such as Ubuntu this means that they will either have to maintain and develop static bindings themselves alone, or move to use introspection. See here for an explanation of how apps in python would use introspection to call GObject C code.

If Ubuntu limited itself to package whatever software upstream releases, they could just sit waiting for new releases and update the dependencies accordingly. But turns out they produce a lot of Python code themselves and thus need to get involved in this transition for their own good. They also have the goal of being a great platform for developing desktop apps with Python, and introspection will play a major role in that.

Jorge Castro was tremendously helpful by presenting myself to Barry Warsaw, who has a responsibility role in Ubuntu's use of Python. Barry has been working on the transition to Python 3 and GNOME's move to introspection can make it way easier by making obsolete an awful lot of CPython code. This will also make possible in the future to use other Python implementations than CPython for coding GNOME applications.

As the week progressed introspection got more and more present in Ubuntu's plans, which makes me very happy. Follows some of the most relevant mentions of it, check the whiteboard section of each blueprint for the details:

How do we get to Python 3 and do we go through 2.7 first? "Port PyGI to python3. Move python2 applications to use PyGI." There's lots we can do upstream to help with this, from providing a script to convert to the new API to create a compatibility layer in PyGI. We'll be discussing the creation of a mailing list for coordinating PyGObject and PyGI development and helping with the porting from the static bindings.

How GObject Introspection will change our platform "Actions: Package PyGI for Ubuntu (Python 2) [robert-ancell], create or hijack a mailing list for pygi development"

Fun and Easy Python API for Telepathy We are adding API to telepathy-glib in this direction and nobody has shown interest in working on new static bindings for it, so we need PyGI in order to access the new API.

packagekit as backend for software-center "Python API is out-of-date. It would require some adaption, especially since 0.6.x will break API. Packagekit-glib2 was written with gobject introspection support. So bindings could be generated in the future."

Review coming changes in GNOME and what we will want to do "Python introspection bindings well progressed at sprint. No resource for GLib introspection work. Libraries will stop making bindings and rely on introspection - we have to migrate at some time to keep bindings"

And there seems to have been also interest in introspection from the people pushing for Midgard in Ubuntu.

In summary, I'm very happy to count on Ubuntu in the development of PyGI, I plan to report in this blog about the progresses in polishing PyGI and porting apps to the new API.

P.S.: I'm under the impression that Planet GNOME is not widely read by Ubuntu people, so if someone could rely it to their planet, would be awesome.

10 comments:

Juanjo Marín said...

Tomeu, thanks for helping to reduce the metacognitive mismatch between Ubuntu and GNOME that lately seems to be increased.

I understand they have their plans and their vision for the desktop, but it would be much better if the keep an eye of what is going on upstream.

Gustavo Carneiro said...

As gnome-python* maintainer, I am looking forward to being able to stop maintaining them in the near future! Especially due to lack of time for GNOME hacking...

Your in the right track; I wish I had time to help out. But keep up the good work :-)

bilboed said...

Same comments as Gustavo but for gst-python. We should have had this ages ago and gobject-introspection/PyGI makes it a reality.
My main concern though are the performance. Having to resolve everything at runtime might not be acceptable for some users of gst-python.

Tomeu Vizoso said...

@bilboed:

> My main concern though are the performance. Having to resolve everything at runtime might not be acceptable for some users of gst-python.

I'm not particularly worried about this because what gets resolved at runtime are classes and other top-level objects, and those get cached for the entire life of the module after they have been referenced from the first time (typically at startup).

What will slow things at runtime is calling the C function through FFI but it may not be noticeable in most cases.

In the extreme cases where the FFI overhead is noticeable (say, a C function is called from Python some thousands of times as response to a single user action), moving that call to a C module would be a good idea.

Tomeu Vizoso said...

@Juanjo:

I agree, but also believe that big upstreams such as GNOME could do a bit more to improve the situation. Something like having a "downstreams team" that aims to improve communication between upstream<->downstream.

To be clear: I don't mean upstreams having to track all their downstreams, just having a place where these issues are discussed.

And thanks for your constant support!

Juanjo Marín said...

Hmm, yes. Good reply. I think you're right, they aren't doing a good job here, but we can do better too.

Definitely, must improve communication with downstream !!! :)

Robert Ancell said...

Hi Tomeu, thanks for coming and giving your expertise in this field. I'm working on getting these changes into Maverick now.

We do have a team in Canonical for improving relationships with upstreams and Jorge is a prominent member! This is the Canonical Community team, led by Jono Bacon:
https://edge.launchpad.net/~canonical-community
http://www.jonobacon.org/2010/04/23/lucid-community-team-review/

Robert Ancell said...

I have reblogged this on Planet Ubuntu:
http://bobthegnome.blogspot.com/2010/05/gobject-introspection-in-ubuntu.html

Tomeu Vizoso said...

@Robert Ancell:

Yes, at the UDS I was able to see that Ubuntu cares about working with their upstreams.

Perhaps the biggest challenge of the free software community is making sure that the money that gets injected into our ecosystem reaches the place where it will have the biggest impact.

Most of the funding will start its travel in a downstream, but downstreams won't want to keep it all there, at the risk of becoming themselves their own primary upstream.

But given how complex and unknown is the FOSS ecosystem, we still have lots to learn before we reach some efficiency.

And yes, Jorge did a great job there from my POV.

Thanks a lot for relaying my post!

James Michael Dupont said...

https://blueprints.launchpad.net/gtk2/+spec/gobject-introspection/ is awol.

also I cannot post the comment:Folgende Fehler wurden gefunden:
Input error: Memcache value is null for FormRestoration