I am Forking LGI, Lua's Bindings to GObject

More options for developing apps can only be a good thing.

July 09, 2025

Forking a free software project is often an ill-advised action. Forking a project just because you disagree with changes that are being made to it is a great way to give yourself an untenable work load as you try to hunt down patches to fix bugs in your aging and less-maintained fork. That isn’t the situation I find myself in.

Lua is my favourite programming language, GNOME is my preferred desktop environment in Linux, and there is only one way to write GNOME apps using Lua: LGI. Though I’ve written a few apps with it, LGI has problems which are unsolvable without forking it.

So, I’ve forked LGI.

Building on work from the excellent Christian Hergert who maintains many critical GNOME projects, this fork now supports girepository-2.0—the latest tool for building bindings to GNOME’s libraries and a necessary library to support for compatibility with the upcoming GNOME 49 platform.

Read on to learn why this fork was done.

The first problem with upstream LGI is that it hasn’t seen a release since 2018. This means I need to ship an experimental development version with my apps in order to use the latest and greatest GNOME technologies.

The reason for the lack of releases—and the second big problem with the upstream—is the fact that its creator and previous maintainer has been offline for over half a decade. There are a few others with access to LGI’s upstream repositories, but they have lost interest in the project. Even if they were actively developing LGI, none have access to the sites necessary to make a new release.

LGI is thus currently in limbo. Without a way to make new releases, it generates less buzz and fails to gain users. Documentation on how to use it is somewhat lacking, which creates a hurdle for newbies. With more difficulty in using, prospective app developers lose confidence in the bindings and begin to look elsewhere. This creates a death spiral where usage of the library eventually plummets, interest fades, and it dies out. For the project to survive, a fork is a foregone conclusion. The only thing in question was who would do it.

Some searching has led me to understand that there are few active free software projects which use LGI. Of these, I only know two: libpeas, and my own counting app Tally. Libpeas is a plugin engine used by some GNOME apps. This means that these apps only use LGI in a way which is non-essential. They don’t depend on it for core functionality and without active development on LGI these projects will simply opt to drop it if it is no longer compatible with modern versions of GNOME’s libraries. Tally, which uses LGI as its foundation, does not have this option. This likely makes me the single most motivated individual to pursue this avenue, so I know when it comes to forking LGI that it’d be either me or no one.

The last question you may ask is: Why even bother with this dying project?

GNOME has numerous actively developed bindings to languages which are far more popular than Lua. It also has tooling to help with app development in these languages. Unfortunately for me, I just cannot grasp these tools no matter how hard I try—and I assure you, I’ve put a lot of effort into doing so. There’s something about my brain that makes it so the specifics of the “easy path” carved out by the brilliant GNOME folk just causes me insurmountable problems. It is my belief that this status quo causes a feedback loop where the only developers who end up contributing to the GNOME ecosystem are a subset of all who are motivated to do so, because the tooling is geared to specific problem-solving approaches which might not be actionable by some with a serious interest in contributing.

As GNOME advertises itself as the desktop environment made for everyone, developer APIs which are inaccessible for some is not a situation in which it should find itself. It took serious dedication on my part to find my path to developing GNOME apps, and it is my hope that the work I will put into this fork will enable prospective app developers to more easily find a way to contribute that works for them.

As for getting everyone onto the new fork… well, libpeas will soon switch to my fork and so will Tally. Both projects have been tested against the fork, and they work. That said, there’s still a lot of work to be done, and as always with projects with internals which are (now a little less) unfamiliar to me, it’ll be a slow process at first. However, I do plan to make a release soon, so that there may finally be a released version of LGI which supports current GNOME platform.