Heads-up: PyGObject & libgirepository

Development
1

Gramps Web image builds started failing today because a the new PyGObject version 3.51.0 released yesterday requires libgirepository 2.0 (rather than 1.0), but it’s not available on Debian bookworm that I use as base image.

I think I will have to manually pin it to 3.50.0 - but it’s annoying because it’s not a direct dependency but comes in through the Gramps dependency.

For Gramps 6.0, we have to decide what to do.

You can find some other bug reports from today in other projects (and there will be more in the coming days), e.g.here Tutorial breaks on step 1 on Ubuntu/Debian · Issue #488 · beeware/beeware · GitHub.

1 Like
2

Looks like we were debugging in parallel (see the comment at the end of my post).

While debugging, I also came across this toga issue. They seem to have this problem as well.

2 Likes
3

A slight aside, but there is no reason when gramps is used as a library, as with gramps-web, that we need to meet all of the GUI requirements. Perhaps for Gramps 6.n we can restructure the imports so that PyGObject wouldn’t be imported. I know that @Nick-Hall started/proposed that a while back. Time to revisit it?

2 Likes
4

Removing GUI code from gramps.gen is a long-term goal. I moved the Gnome thumbnailer code into a plugin for that reason.

Some non-GUI modules may require PyGObject though.

1 Like
5

I wonder if there aren’t good modern replacements for any non-gui PyGObject functions?

1 Like
6

Try 3.52.1 - 3.51.0 has already been withdrawn.

2 Likes
7

The problem is not the yanked release, the problem is actually 3.52.1 which was released on March 9th. So starting with this release, pip-installation of PyGObject (and thus Gramps) will fail even on fairly recent distros like Debian Bookwork or Ubuntu 22.04 LTS.

8

I solved this for Web API now by pinning PyGObject <=3.50.0.

1 Like