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

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

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.

Remove the optional `systemd-python` dependency (#19491)

@sandhose

@sandhose The log you are showing, is from an old version which uses setuptools as build backend, not mesonpy.
The version with mesonpy is not released yet. When it is released, it will allow to publish wheel files and metadata to PyPI and people without libsystemd won't get trouble (because uv doesn't need to try to build systemd-python on developer machine).

I think just publishing a newer release will solve this issue. Even re-releasing v235 with a newet setuptools version might fix it. I looked a bit further into this...

Context: We are adopting renovate-bot in some repos. As part of the updates it will regenerate lockfiles, in the case of uv it will call uv --lock. This in turn will instruct uv to determine certain metadata. As there are no wheels fetches these from the source distribution (sdist) and therein looks for a pyproject.toml and PKG-INFO file. The latter exists, however, it has Metadata-Version: 2.1 which means that any field is assumed to be "dynamic". This prevents uv from using that file and instead in needs to build the wheel itself (https://docs.astral.sh/uv/reference/troubleshooting/build-failures/#why-does-uv-build-a-package). As uv sync also updates the lockfile I assume this is also the cause for this issue.

My best guess is that simply republishing a new 235.1 with the old code but a newer setuptools version would already fix this. Generally, publishing wheels would be much appreciated but maybe this could be a good quick solution?

PS: Running python3 -m build on the v235 tag (and no further changes) and tar --to-stdout -axf dist/systemd_python-235.tar.gz systemd_python-235/PKG-INFO shows Metadata-Version: 2.4

So I think branching there and releasing a 235.1 would be good :)

newet setuptools version might fix it

It will not, because of the way this project's setup.py script is written. See my explanation here: #148

Running python3 -m build on the v235 tag

That -m build command works thanks to the switch to pyproject.toml and mesonpy.

Running python3 -m build on the v235 tag

That -m build command works thanks to the switch to pyproject.toml and mesonpy.

As written, I ran it on the old version and it worked fine, so the switch to mesonpy can not possibly have affected it. It also generated a new PKG-INFO file which should be sufficient for UV to avoid building a wheel. Please see the documentation I linked (I also did quite a code dive into uv to confirm this as best as I could).

@septatrix

Indeed, I assumed that the published version was already using mesonpy. I did try to build a sdist with the latest main (python -m build), then used the sdist locally with uv add ../python-systemd/dist/systemd_python-236.tar.gz -m "sys_platform == 'linux'" works.

As @septatrix pointed out, it even works when checking out the v235 tag and building an sdist with python -m build. Not sure what's up there 🤔

As @septatrix pointed out, it even works when checking out the v235 tag and building an sdist with python -m build. Not sure what's up there 🤔

As I said, the reason uv currently refuses the sdist is because the metadata file therein (PKG-INFO) has too old of a version which is unfit for uv. Simply rebuilding it generates a metadata file conforming to a newer spec version enabling uv to rely on it.

Thanks, I may be wrong.

Remove the optional `systemd-python` dependency (element-hq#19491)

A new version has just been tagged, can you check whether this resolves your issue?

Not unless you also publish a new version to pypi.

Yeah, we're working on it. The publishing has to be fixed unfortunately.

Will v236 also include pre-built wheels on pypi? Exciting if so.

I'm looking into that.

May I ask what the state of publishing to PyPI is?

Ping?

If someone cannot wait for new release of systemd-python and just want some library to write to journald, you can take journald-send a look.

@behrmann

Any update @behrmann?

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

behrmann commented on Feb 21, 2026

hongquan commented on Mar 16, 2026

septatrix commented on Mar 23, 2026

septatrix commented on Mar 23, 2026

hongquan commented on Mar 24, 2026

hongquan commented on Mar 24, 2026

septatrix commented on Mar 24, 2026

sandhose commented on Mar 24, 2026

septatrix commented on Mar 24, 2026

hongquan commented on Mar 24, 2026

behrmann commented on Jun 18, 2026

DerBiasto commented on Jun 18, 2026

behrmann commented on Jun 18, 2026

jvolkman commented on Jun 22, 2026

behrmann commented on Jun 23, 2026

septatrix commented on Jul 1, 2026

septatrix commented on Jul 14, 2026

hongquan commented on Jul 16, 2026

septatrix commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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