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

[sandhose]

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: mesonbuild/meson-python#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

[behrmann]

I don't think your solution in #168 is unreasonable. I think something like this would be reasonable to add, since even know there are Linux distributions around that don't have libsystemd and are wildly used in the container space, so even with the constraint sys_platform == 'linux', this might very well fail. It would be easier if python-systemd could always be included as a dependency and would not need to be sequestered as an optional dependency.

The meson-python stance does not sound entirely not entirely reasonable, since not all information can be statically known (e.g. the version), and if I'm not mistaken they do support editable installs nowadays. Though, I've yet to read the thread fully.

That being said, uv's approach does sound problematic to me here as well, for the problem you are running into. Could you open an issue? The astral folk are usually extremely receptive and quick to act on reports and all around lovely to work with.