[DRAFT] Port to girepository-2.0 #337

chergert · 2025-05-30T20:59:36Z

This is an initial port of lgi to use girepository-2.0 introduced in the GLib 2.80 release.

If using 2.85, it will use the new gi_repository_dup_default() function to ensure the repository is using the same repository as applications and libraries such as libpeas.

There is still some work to be done, as libpeas tests do not yet pass using this version of lgi. But I wanted to get some feedback on things and some extra eyes.

In particular, I'm seeing this when running the libpeas unit tests.

** (/home/christian/Projects/libpeas/build/tests/libpeas/extension-lua:331247): WARNING **: 13:35:52.864: Error loading plugin 'extension-lua51':
/home/christian/.jhbuild/share/lua/5.1/lgi/class.lua:354: bad argument #8 to 'register_static' (number expected, got table)
stack traceback:
	[C]: in function 'register_static'
	/home/christian/.jhbuild/share/lua/5.1/lgi/class.lua:354: in function 'derive'
	.../tests/libpeas/plugins/extension-lua/extension-lua51.lua:26: in main chunk
	[C]: at 0xfffef9ea86e0
	[C]: in function 'xpcall'

Which has code like:

-- Register new type with GType system.
local gtype = register_static(self._gtype, g_typename, type_info, {})

and presumably the failure is converting the {} to the flags.

Anyway, still trying to dig that out.

This is an initial port of lgi to use girepository-2.0 introduced in the GLib 2.80 release. If using 2.85, it will use the new gi_repository_dup_default() function to ensure the repository is using the same repository as applications and libraries such as libpeas. There is still some work to be done, as libpeas tests do not yet pass using this version of lgi.

psychon · 2025-05-31T15:28:52Z

But I wanted to get some feedback on things and some extra eyes.

Sorry, but I do not thing there is anyone around who can give you that. Personally, I only ever poked at specific bits and pieces when something failed / broke and hoped that Pavouk knew what was going on. And now I do not thing anyone is around who really understands "all the magic".

Sorry.

psychon

I scrolled through this and commented what I noticed, but... dunno. I have not much clue about any of this.

Out of curiosity, what would happen if LGI just continued using gobject-introspection-1.0 instead of switching to girepository-2.0? What does this switch mean for any downstream users?

Also, you only touched meson.build. Is the Makefile still fine?

psychon · 2025-05-31T15:35:22Z

lgi/gi.c

+    repository = gi_repository_dup_default ();
+#else
+    repository = gi_repository_new ();
+#endif


A quick google session suggests that these two function do very different things. I am still not sure about the details, but things sound complicated....

psychon · 2025-05-31T15:35:56Z

lgi/gi.c

-	  luaL_getmetatable (L, LGI_GI_INFO);
-	  lua_setmetatable (L, -2);
-	}
+      g_assert (GI_IS_BASE_INFO (info));


What happened to the lua_pushnil() case?

psychon · 2025-05-31T15:38:00Z

lgi/gi.c

 #if !GLIB_CHECK_VERSION(2, 30, 0)
-/* Workaround for broken g_struct_info_get_size() for GValue, see
+/* Workaround for broken gi_struct_info_get_size() for GValue, see
   https://bugzilla.gnome.org/show_bug.cgi?id=657040 */


Are you sure that bug report is about broken gi_struct_info_get_size()? I am not sure about the history / timeline, but this seems weird.

psychon · 2025-05-31T15:38:55Z

lgi/object.c


 /* This is workaround method for broken
-   g_object_info_get_*_function_pointer() in GI 1.32.0. (see
+   gi_object_info_get_*_function_pointer() in GI 1.32.0. (see


Does gi_object_info_get_*_function_pointer() even exist in GI 1.32.0?

ildar · 2025-05-31T15:58:29Z

Out of curiosity, what would happen if LGI just continued using gobject-introspection-1.0 instead of switching to girepository-2.0? What does this switch mean for any downstream users?

GNOME devs are forcing the migration. E.g. gEdit dropped (I hope temporarily) the support of Python plugins because of this.

IMHO gir2 support in vital for the project to work together with newer GNOME projects, given that gir1 and gir2 can't coexist in one app.

luau-project · 2025-05-31T17:01:34Z

This is an initial port of lgi to use girepository-2.0 introduced in the GLib 2.80 release.
.
.
.
But I wanted to get some feedback on things and some extra eyes.

Since you asked for feedback, I'm gonna drop a few words. Do not judge it as criticism, but just as my sincere wishes.

I see it as a good practice to move forward on dependent library versions. However, for such a stable library as LGI is, I'm not sure whether it is viable or not, it would be really nice to keep compatibility with girepository-1.0. From your edits so far, mostly renaming function calls, it seems like that with proper macros, it could be handled.

What I mean is:

#ifdef LGI_GIREPOSITORY_1_0
    /* legacy code goes here */
#else
    /* 2.0 code goes here */
#endif

on each replacement, or define most of them on a shared header file and import it when needed.

chergert · 2025-05-31T17:46:06Z

on each replacement, or define most of them on a shared header file and import it when needed.

You could probably make the functions that now return boolean instead of -1 values do that. But I don't have the time/motivation to do so.

I also don't really see the value in it. For the things that need gobject-introspection-1.0, they probably wouldn't be on an updated system anyway. I also have skepticism that many projects would exist that fit that constraint.

chergert · 2025-05-31T17:46:58Z

GNOME devs are forcing the migration. E.g. gEdit dropped (I hope temporarily) the support of Python plugins because of this.

I have this mostly fixed for libpeas for the 2.x branch, and will have it fixed for libpeas-1.x for GNOME 49. It does require an ABI break technically but should at least allow things to move forward.

chergert · 2025-05-31T17:49:08Z

Out of curiosity, what would happen if LGI just continued using gobject-introspection-1.0 instead of switching to girepository-2.0? What does this switch mean for any downstream users?

I would have to drop Lua support from libpeas-1.x and libpeas-2.x starting with GNOME 49 (releases in September).

Also, you only touched meson.build. Is the Makefile still fine?

I didn't touch the Makefile, mostly because I didn't even notice it was there.

I want to be clear about my availability to push through on this though. I don't really have any work cycles to do any of this so this was me stealing about a day to work through some things. I can't commit to pushing forward on it any more than this.

The side-effect will be, however, that if it doesn't happen, I have to drop Lua support for libpeas soon.

vtrlx

Stumbled onto this PR and decided to test it as I have a GNOME app using this binding so I'm very interested in ensuring it can continue to be updated for GNOME 49. For the purpose of Adw/Gtk applications, all that's needed here is a single change which I've included in the review.

As an aside, while running an Adw/Gtk application with the aforementioned change, I get an error in the terminal every time I instantiate an object from Adw or Gtk:

(process:248015): GLib-GIRepository-CRITICAL **: 13:12:25.881: gi_base_info_unref: assertion 'GI_IS_BASE_INFO (info)' failed

Made some changes to how gi_base_info_unref is called from the LGI side but it didn't affect this message. Just noting here—but aside from this odd detail, my suggested change puts this PR into a working state for writing apps.

lgi/marshal.c

Co-authored-by: Victoria Lacroix <[email protected]>

chergert force-pushed the wip/girepository-2.0 branch from 5ae577d to 4683e39 Compare May 30, 2025 22:53

psychon reviewed May 31, 2025

View reviewed changes

vtrlx reviewed Jun 20, 2025

View reviewed changes

lgi/marshal.c Outdated Show resolved Hide resolved

Update lgi/marshal.c

a833e11

Co-authored-by: Victoria Lacroix <[email protected]>

[DRAFT] Port to girepository-2.0 #337

Are you sure you want to change the base?

[DRAFT] Port to girepository-2.0 #337

Uh oh!

Conversation

chergert commented May 30, 2025

Uh oh!

psychon commented May 31, 2025

Uh oh!

psychon left a comment

Choose a reason for hiding this comment

Uh oh!

psychon May 31, 2025

Choose a reason for hiding this comment

Uh oh!

psychon May 31, 2025

Choose a reason for hiding this comment

Uh oh!

psychon May 31, 2025

Choose a reason for hiding this comment

Uh oh!

psychon May 31, 2025

Choose a reason for hiding this comment

Uh oh!

ildar commented May 31, 2025

Uh oh!

luau-project commented May 31, 2025

Uh oh!

chergert commented May 31, 2025

Uh oh!

chergert commented May 31, 2025

Uh oh!

chergert commented May 31, 2025

Uh oh!

vtrlx left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants