Showing up for Python in GNOME

A few years ago, PyGObject—the Python package that provides bindings for GTK and GNOME applications—was not faring particularly well. Several maintainers had left the project and its development was not keeping pace with changes in GTK. At this year's GUADEC, Dan Yeaw presented a talk about the project's decline, improvements in the last year, and his experience getting involved in an undermaintained project.

Yeaw said that he worked for Ford Motor Company in functional safety, and part of his job was to do systems modeling to help ensure that "complex systems don't malfunction and cause harm". He wanted to be able to do that with open-source software, which led him to a project called Gaphor, a modeling application written in Python, about six years ago. From there, he got involved in the Python community and helping to "fix pain points" he encountered running Gaphor on Windows. In the past year, he had started contributing to PyGObjects.

Yeaw explained that he felt Python should be a language of choice for writing GNOME applications. Python was easy to learn, he said, and "scales easily with your skill set". It's suitable for kids to pursue their interests and learn just what they need, but it's also used by researchers, students, data scientists, web developers, and many others. His ten-year-old son was already writing simple games with Python, and had embarked on a larger project, making a Pokédex to keep track of Pokémon.

Yeaw also said that it had "never been easier" to build an application for GNOME thanks to applications like Builder, Workbench, and Cambalache. Flatpak, likewise, makes it easy to package them. Python is the perfect "big tent" language that makes it easy for anyone to build applications, but "we need to make sure the GNOME experience with it lives up to this" so all of the people using Python will join the community.

Call to action

The problem was, PyGObject was not living up to this. He referenced a blog post that Emmanuele Bassi wrote at the end of 2022 with a "call to action" for others to get involved in the project. Bassi said that PyGObject was "undermaintained, even after the heroic efforts of Christoph Reiter to keep the fires burning" and needed more people from the Python community to pitch in "if we want Python to be a first class citizen of the ecosystem".

Bassi had three major complaints about the state of PyGObject. First, it was missing support for several GTK4 types, including GtkExpression. Bassi said that "not having access to the expressions API makes writing list widgets incredibly more complicated". Secondly, PyGObject did not have automatic access to the constructing and disposing virtual functions, making it much harder in GTK4 to create and remove child widgets. And, finally, the documentation was spread out over several sites, and missing important components, like a tutorial for GTK4.

The project was running on fumes, with only one primary maintainer (Christoph Reiter) still keeping the project alive. Other major contributors had left the project, which Yeaw pointed out is a natural part of open-source projects. He showed a slide (page six in this presentation) that illustrated the drop off in commits over time.

Challenges getting involved

There's a catch-22 in getting involved in projects that are unmaintained or undermaintained, Yeaw said. When few people—or even a single person—are doing all the work, they have little time to spare to help newcomers get up to speed. Community building, he said, "requires many hands to get involved to help newcomers triage issues, answer questions, and provide support". If the person maintaining the project does not have the time to manage issues or address merge requests, it does not feel welcoming to the new contributors. And then, often, those contributors go where they feel their work will make more of a difference.

It is even worse with GNOME, Yeaw said, because there are extra layers of complexity to figure out. "It kind of feels like GNOME is this walled city, and you're at a gate and trying to knock and there's no one there." Here he gave a shout-out to the recently released GNOME Handbook as a resource to help people get involved.

It should not take someone like Bassi writing a blog post to elicit involvement in a struggling project, Yeaw said. He suggested that the GNOME Foundation or other communities consider ways to track key GNOME projects with metrics and provide community building support for at-risk projects before it becomes a problem.

Getting better

The project has made a number of improvements in the past year, he said. It has made "major inroads" to reducing the number of total issues and outstanding merge requests. The project has closed more than 200 issues to bring the total number down from more than 300 to 175. Although there are still more than he would like, "getting issues in the 100 to 200 range is something that contributors can get their head around. Much more than this can feel overwhelming".

The project has added some of the fundamental types that are used by GTK4 and its related libraries. Yeaw walked through an example of using the Workbench application to create a table that would sort book data. GTK4 provides an easy way to do this by using the Gtk.Expression type, but that had been missing from PyGObject. The implementation to support that had been in the works since 2010, but Arjan Molenaar "brushed it off and brought it home this year".

In addition, the community has been working to centralize the documentation for PyGObject. The project's documentation was, previously, hosted on Read the Docs, which is often home to Python project documentation. The existing documentation, plus a guide by Rafael Mardojai, were re-licensed from the GNU Free Documentation License (GFDL) to LGPL and merged with other documentation on the PyGObject project site.

The project has also modernized the way it builds its API documentation, by moving from GTK-Doc to GI-DocGen, which reuses introspection data generated by GObject-based libraries to generate API references. This means, he said, that previously missing documentation for things such as Gtk.Template were now available, and that the API documentation would require less maintenance in the future.

Another major change that Benjamin Berg had been working on for two years, and which had just landed the week before GUADEC, is initial support for asynchronous I/O (asyncio).

The future

Of course, the work of maintaining a project like PyGObject is never really done. Yeaw had a few things that he expected the project to tackle in the future. The first one he discussed, possibly of lesser interest for LWN readers, is building wheels with the dynamic link libraries (DLLs) included. The reason for this is that Python 3.8 and later changed the way that DLLs are loaded on Windows for security reasons. This means that applications that relied on the old behavior would have to manually handle loading DLLs. The plan is to build wheels of PyGObject with the necessary DLLs included, which he said would also "significantly improve install time".

Yeaw also said that there was work to port PyGObject to libgirepository 2.0, which he described as "more of a chore" to ensure that the project was using the latest libraries. That work had been started by Philip Withnall and was being picked up by Molenaar. The project is also working to combine and merge the API documentation to the PyGObject site, which would centralize all of the Python for GNOME documentation.

Yeaw closed by asking attendees to get involved with PyGObject, and thanking all the contributors who had helped with the project so far. He asked for help with any kind of contribution, whether that was submitting bug reports or triaging issues, improving documentation, fixing bugs, implementing new features, or simply building new applications using PyGObject.

The "Showing up for Python in GNOME" talk is available on YouTube.