Python packaging tools can't resolve the package metadata without `libsystemd`

Start by reproducing the uv sync failure for systemd-python==235 on a non-Linux platform without libsystemd, then read the Meson build configuration and the linked meson-python issue. Evaluate the proposed optional C-extension approach; done means package metadata can be resolved without those libraries while preserving the stated runtime behavior.

I ran into this whilst trying to move my project to replace poetry with uv.

One interesting property of uv, is that it creates a lockfile that works for all platforms. This means that even if systemd-python is only installed on Linux ("systemd-python>=231; sys_platform == 'linux'" in the dependencies), it needs to be able to resolve the package metadata.

The problem is, as far as I can tell, mesonpy always run the meson build, even just for resolving the package metadata. And because the current meson build will hard-fail if libsystemd isn't available, regardless of the platform, it makes generating/updating the uv lockfile impossible on non-linux platforms.

❯ uv sync
  × Failed to build `systemd-python==235`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit status: 1)

      [stderr]
      Cannot find libsystemd or libsystemd-journal:

      Package libsystemd was not found in the pkg-config search path.
      Perhaps you should add the directory containing `libsystemd.pc'
      to the PKG_CONFIG_PATH environment variable
      No package 'libsystemd' found

      Package libsystemd-journal was not found in the pkg-config search path.
      Perhaps you should add the directory containing `libsystemd-journal.pc'
      to the PKG_CONFIG_PATH environment variable
      No package 'libsystemd-journal' found


      hint: This usually indicates a problem with the package or the build environment.
  help: `systemd-python` (v235) was included because `matrix-synapse[systemd]` (v1.148.0rc1) depends on `systemd-python>=231`

Some background about this issue on the mesonpy side can be read here: https://github.com/mesonbuild/meson-python/issues/236

Now, this could be solved by making the C extension optional, and throw at runtime if it was built without it. It's not ideal, it would stop failing at build-time, but would make it possible to use python-systemd in projects using uv without requiring libsystemd to be available

Another very creative solution would be to write a special build backend which delegates to mesonpy in most cases, but provides its own prepare_metadata_for_build_wheel implementation… but that feels a bit overkill

Last but not least, using another build backend than mesonpy could be a solution, but definitely more involved.

I'll put up a draft PR for the first solution shortly to let you evaluate how that feels