Pypi.org unsupported platform tag 'openbsd_7_0_amd64'

I’ve just tried to upload an OpenBSD wheel to pypi.org with twine, and it failed with

unsupported platform tag 'openbsd_7_0_amd64'

Is this expected behaviour for pypi.org? My setup.py uses setuptools so i’m assuming that the platform tag was correctly generated.

I built the wheel with:

python setup.py bdist_wheel

- and pip succesfully installs it into a venv locally.

Thanks for any help,

- Jules

This is expected behavior for PyPI. We use the manylinux standard instead of supporting every possible Linux distribution.

See https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#platform-tags-for-common-linux-distributions for more details.

But OpenBSD is not a Linux distribution.

So it cannot use the manylinux standard.

Thanks,

- Jules

1 Like

Correct, but no one has proposed a manybsd standard or equivalent for other Unix OSs which are not ELF-based or don’t use glibc (there is a musllinux prefix for musl-based Linux distros).

I’m not sure whether it was meant in this way, but i don’t think a “manybsd” standard makes sense - OpenBSD, FreeBSD, NetBSD etc are each different operating systems and there’s no simple way to create a wheel that somehow works on all of them.

Assuming what was meant is a “manyopenbsd” standard, i think this would be unnecessary. The OpenBSD kernel and libraries are packaged together in each release so there’s no worry about trying to support different combinations of kernel and libc versions. Instead the OS version number is always enough to identify both kernel and libraries on the system.

OpenBSD is similar to Windows and MacOS in this regard.

So i think that platform tags such as “openbsd_7_0_amd64” should ideally be accepted on pypi.org.

- Jules

Does OpenBSD have a strict ABI backwards compatibility policy? Would a openbsd_7_0_amd64 wheel work on OpenBSD 7.1 or 8.0?

No, i don’t think there is strict ABI backwards compatibility.

So one would require separate openbsd_7_0_amd64 and openbsd_7_1_amd64 wheels, for example.

[Only the most recent two OpenBSD releases are usually supported. Users are generally encouraged to upgrade when a new release comes out every 6 months, and this has been made as easy as possible - just run sysupgrade in a terminal.]

- Jules

In my opinion the lack of stable ABI support disqualifies OpenBSD from becoming a supported tag on PyPI. The manylinux and manymusl binary wheels work on vast majority of Linux distros because they use stable subset of common ABIs. This allows our community to build binaries for a large user base without constantly updating build systems and compiling new wheels. Platform support isn’t particularly useful without community involvement.

Platform support on PyPI involves more than just allowing a wheel tag:

  • Does the platform have a long-term stable ABI?
  • Is the platform officially supported by Python? PEP 11 – CPython platform support | peps.python.org
  • Are there public CI and build providers so that OSS projects can test and build their projects with reasonable effort and time?

OpenBSD has neither a stable ABI, CPython support tier nor support from major CI providers.

2 Likes

Oh, that’s a shame. For Python packages that are updated reasonably often, new wheels would be naturally produced often enough to match the 6-monthly OpenBSD release cycle.

I.e. i don’t think that the lack of a long-term stable ABI should necessarily be a reason for not supporting a particular platform on pypi.org; it is still useful to have wheels available for short-term stable ABIs.

I can’t argue with your points about official support, and public CI and build providers.

However i’m not sure i see a downside to pypi.org hosting wheels for officially unsupported platforms where a packager is willing to provide them. And couldn’t it be argued that this might broaden community engagement with Python and even encourage such platforms to get onto the list of support tiers?

Thanks,

- Jules

One of the biggest problems on Linux which the manylinux specification was intended to solve was specifying exactly what external libraries wheels are allowed to depend on. This avoids the problem of 2 wheels, both supposedly valid for a given platform, being incompatible because they depend on different versions of some 3rd party library.

The latest manylinux specification words this quite loosely, but puts the responsibility squarely on the wheel creator (and there is a manylinux toolchain set up to support wheel creators in fulfilling that responsibility):

the wheel’s creator promises that the wheel will work on any mainstream Linux distro that uses glibc version ${GLIBCMAJOR}.${GLIBCMINOR} or later, and where the ${ARCH} matches the return value from distutils.util.get_platform().

The question here is whether a similar promise would work for openbsd - if openbsd_7_0_amd64 wheels were required to work on every installation of openbsd 7.0 on amd64, would that be achievable for wheel builders? Simply building a wheel from C code using setuptools may not be sufficient, as that could pull in references to locally-installed libraries which may not be guaranteed available on all openbsd 7.0 systems. If setup.py bdist_wheel doesn’t do enough to guarantee such a promise, the openbsd community will need to set up some sort of tooling that addresses that.

Please be aware that I know nothing about openbsd, so I don’t know (for example) whether it’s possible for two installations of openbsd 7.0 to have incompatible X Windows library versions installed.

1 Like

I hesitate to speak for OpenBSD here, but my understanding is that each release comes with an associated set of packages, and it is not possible to upgrade a library package to a version that is not backwards-compatible. And fundamental things like libc are (almost?) never updated within a release cycle.

So, yes, i think it is trivially achievable for an openbsd_7_0_amd64 wheel to work on every installation of OpenBSD 7.0 on amd64.

I guess that OpenBSD’s relatively short 6-monthly release cycle helps make this work, as does the way that each release integrates the kernel and libraries.

[A related question - what happens if a Python package requires specific libraries to be installed on the system, instead of bundling them internally? Does the Python packaging infrastructure ever interact with the OS packaging system and ask for particular OS packages to be installed?]

Thanks,

- Jules