PyGObject>=3.51.0 depends on libgirepository 2.0

[rmartin16]

Describe the bug

As explained in GNOME/pygobject#320, PyGObject now depends on libgirepository-2.0. This is somewhat curious because it seems to deprecate support for non-EOL platforms like Ubuntu 22.04.

❯ python -m pip install https://gitlab.gnome.org/GNOME/pygobject/-/archive/3.51.0/pygobject-3.51.0.tar.gz
Collecting https://gitlab.gnome.org/GNOME/pygobject/-/archive/3.51.0/pygobject-3.51.0.tar.gz
  Using cached https://gitlab.gnome.org/GNOME/pygobject/-/archive/3.51.0/pygobject-3.51.0.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error
  
  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [23 lines of output]
      + meson setup /tmp/pip-req-build-il55zbly /tmp/pip-req-build-il55zbly/.mesonpy-f16updav -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md -Dtests=false -Dwheel=true --wrap-mode=nofallback --native-file=/tmp/pip-req-build-il55zbly/.mesonpy-f16updav/meson-python-native-file.ini
      The Meson build system
      Version: 1.7.0
      Source dir: /tmp/pip-req-build-il55zbly
      Build dir: /tmp/pip-req-build-il55zbly/.mesonpy-f16updav
      Build type: native build
      Project name: pygobject
      Project version: 3.51.0
      C compiler for the host machine: cc (gcc 11.4.0 "cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
      C linker for the host machine: cc ld.bfd 2.38
      Host machine cpu family: x86_64
      Host machine cpu: x86_64
      Program python3 found: YES (/home/russell/.pyenv/versions/briefcase-3.10/bin/python)
      Found pkg-config: YES (/usr/bin/pkg-config) 0.29.2
      Run-time dependency python found: YES 3.10
      Found CMake: /usr/bin/cmake (3.22.1)
      Run-time dependency girepository-2.0 found: NO (tried pkgconfig and cmake)
      Not looking for a fallback subproject for the dependency girepository-2.0 because:
      Use of fallback dependencies is disabled.
      
      ../meson.build:31:9: ERROR: Dependency 'girepository-2.0' is required but not found.
      
      A full log can be found at /tmp/pip-req-build-il55zbly/.mesonpy-f16updav/meson-logs/meson-log.txt
      [end of output]
  
× Encountered error while generating package metadata.
╰─> See above for output.

Steps to reproduce

Attempt to install PyGObject 3.51.0 on a system without libgirepository 2.0.

python -m pip install https://gitlab.gnome.org/GNOME/pygobject/-/archive/3.51.0/pygobject-3.51.0.tar.gz

Expected behavior

Documentation is updated to reflect dependency changes.

• For Ubuntu 24.04+, install libgirepository-2.0-dev instead of libgirepository1.0-dev
• Fedora 40 & 41 work as documented
• Arch Linux works as documented
• openSUSE Tumbleweed works as documented

Support for installing Toga on Debian 12 and Ubuntu 22.04 is somehow retained.

Screenshots

No response

Environment

• Operating System: pop os 22.04
• Python version: 3.10
• Software versions:
  • Toga: 0.4.8

Logs

No response

Additional context

No response

[freakboy3742]

Good catch getting ahead of this - I imagine this will be picked up by dependabot in about 24 hours when it tries to update pygobject.

However, this is a really hard one to accomodate. Either we pin pygobject==3.50.0, or we abandon support for Debian 12/Ubuntu 22.04 et al. There's no pip install marker we can apply that will gate on system dependencies, so we can't qualify our usage of pygobject. Or, I guess, we try and document how to install libgirepository 2.0 from source as well... which... I'll pass on that option, thanks :-)

The somewhat mercenary answer here is that there's an extent to which this is Linux (or at least Ubuntu/Debian) behaving as expected. Debian 12/Ubuntu 22.04 ships with a version of pygobject; the "Debian way" is that you should be using that version. Installing pygobject from source is already pushing things a little.

It's at least somewhat unreasonable to use an 3 year old release and expect all the latest features to be available; maybe this is just the trigger for us to drop Debian 12/Ubuntu 22.04 support. That would put Debian/Ubuntu support on a similar timeframe to Fedora and OpenSUSE, which essentially only supports releases for around year after initial release.

@danyeaw I don't suppose you've got any other ideas on how we could manage this while retaining support for older Debian-based releases?

[danyeaw]

We released PyGObject 3.51.0 for GNOME 48 beta and 3.52.0 will be the stable release for GNOME 48. Although now we are talking about this, maybe it really deserves a major version bump.

I don't have any real ideas here besides we need to use the libraries shipped with the user's distro or if someone wants something more recent than that than building against the Flatpak SDK is the answer. I think supporting the last LTS is more containable than trying to support the previous LTS, especially if it is our goal to be able to keep fairly current with the latest desktop standards on Linux. I don't think it is even unreasonable to expect that Desktop App developers are running the latest released version of their distro.

[rmartin16]

There are several competing priorities that all have merit. My two cents for Toga, though, is I think it should continue supporting more than the current LTS. Or at least some level of commitment to overlap when a new LTS is released. Otherwise, I think it stands to particularly limit the usability of Toga for Linux.

Currently, Ubuntu 24.04 has been available for 9 months; personally, I'm still on 22.04. And if we consider Debian, 12 is the only currently supported version available right now. So, maybe we could update the templates to add sections for jammy and bookworm so they continue using pygobject==3.50.0. Or something similar to this.

[freakboy3742]

Well this is fascinating.

In the process of trying to fix #3154, I started getting the failure because pygobject 3.51.0 requires libgintrospection 2.0. If figured I'd just bump the binary dependency to get the tests passing in CI... but then CI started failing for a different reason:

Collecting pygobject>=3.50.0 (from toga-gtk==0.4.9.dev582+ge81330802)
  Downloading pygobject-3.51.0.dev0.tar.gz (1.1 MB)
25l     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0.0/1.1 MB ? eta -:--:--
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 83.9 MB/s eta 0:00:00
25h  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Installing backend dependencies: started
  Installing backend dependencies: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'done'
Discarding https://files.pythonhosted.org/packages/e2/07/6e0ed8727d8514ed10755a6b2c8a48f690a566c24bb0601e0f9a88e80912/pygobject-3.51.0.dev0.tar.gz (from https://pypi.org/simple/pygobject/) (requires-python:<4.0,>=3.9): Requested pygobject>=3.50.0 from https://files.pythonhosted.org/packages/e2/07/6e0ed8727d8514ed10755a6b2c8a48f690a566c24bb0601e0f9a88e80912/pygobject-3.51.0.dev0.tar.gz (from toga-gtk==0.4.9.dev582+ge81330802) has inconsistent version: expected '3.51.0.dev0', but metadata has '3.51.0'
  Downloading pygobject-3.50.0.tar.gz (1.1 MB)
25l     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0.0/1.1 MB ? eta -:--:--
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 89.2 MB/s eta 0:00:00

So - PyPI contains a released tarball for pygobject==3.51.0.dev0... but it's internally tagged as 3.51.0 - so it can't be installed. As a workaround, I've pinned pygobject==3.50.0 in #3155.

---

Back to the meta-issue: I completely agree that dropping 22.04 support isn't the most desirable option.

I hadn't considered fixing this at the Briefcase level. Adding a requires clause for bookworm and jammy that enforces pybobject==3.50.0 is fairly elegant - it lets us specify >= 3.50.0 at the Toga level, but allows for older distros to apply an additional constraint (and install the alternate binary package).

It does come with some complications, though. Firstly, the bootstrap API doesn't currently have explicit support for distro version-level configuration - or ubuntu level configuration for that matter. We might be able to shoehorn it into the debian config, but it's not exactly elegant. Secondly, it means that we're hard-locked to PyGObject 3.50.0 on older releases. If there's a bug that pygobject fixes in a later release, Ubuntu 22.04 users won't get that fix. That's not an immediate problem (I'm not aware of anything in 3.51.0 that is a critical must have), but it seems inevitable it's going to be an issue sooner rather than later.

Outside Briefcase, it also leaves "standard pip install" users at a bit of a loose end - but then, we've never managed binary dependencies for those users anyway. The best we can do for them is to document those dependencies.

I wonder if that might be the best approach here - document what we know about the problem.

In Toga, we document the dependency chains and known issues with pygobject versions; but we make it clear that 22.04 support is "best effort", that we're not actively testing it, and that the pygobject issue puts a bit of a limit on the lifespan of that support.

In Briefcase, we internally document the existing Toga bootstrap as being "24.04-compliant", with documentation that additional configuration will be needed to also support 22.04 or earlier. We also add some platform quirk notes to the system backend pointing out that Ubuntu's LTS lifespan can require lots of configurations, and it won't always be possible to install the latest software with the oldest LTS, providing details about how to do the "additional version constraint" trick, and pointing to Flatpak as a possible workaround.