The GI api (or: shouting into the void)

[FeRDNYC (Frank Dana)]

(This is just me thinking out loud (or perhaps lamenting out loud), I’m fully cognizant of the fact that we’re way, way too far down the path to change direction now.)

You ever think, purely from a Python perspective, that it would’ve completely transformed the GI API, had it just presented this interface, instead?

from gi.repository import GLib, Gtk3 as Gtk, Gdk3 as Gdk

No red squiggles on every import statement, from pissing off Flake8:

We wouldn’t have to jump through, frankly, insane hoops just to get type definitions installed properly:

From the pygobject-stubs README:

Configuration

Some libraries exist in multiple versions like Gtk3/4. As both libraries are currently imported under the namespace Gtk only stubs for one can be installed.

You need to decide this at install time either by using the --config-settings option with pip

$ pip install pygobject-stubs --no-cache-dir --config-settings=config=Gtk3,Gdk3,Soup2

or by setting the PYGOBJECT_STUB_CONFIG env variable

$ PYGOBJECT_STUB_CONFIG=Gtk3,Gdk3,Soup2 pip install --no-cache-dir pygobject-stubs

If no configuration is set, the most recent version of each library is installed.

--no-cache-dir is only necessary on subsequent reinstalls, otherwise the stubs will not be rebuild and a cache of a previous installation is used.

Project Integration

Usually you want the stubs to be installed as part of the development dependencies. pyproject.toml does not allow to pass config-settings to requirements. If you need specific versions of some libraries you can use a requirements.txt file instead, which allows to pass config-settings per requirement as of pip >= 23.1.0.

$ pip install . -r dev.txt

Heck, type stubs could be bundled right with PyGObject itself.

*sigh* Oh, well. C’est la vie.