Package with pre compiled shared libs

Hi everyone,

I’ve created a simple Python package that serves as a wrapper for a C library. It supports Windows, Linux, and macOS. Since each platform requires a different precompiled library, I’ve included three platform-specific wheels containing the respective libraries.

However, I noticed that the wheels I’ve published are tagged for Python 3.13 specifically. My question is:

  1. Should the current wheels be installable on older Python versions (e.g., 3.9, 3.10, etc.)?
  2. If not, is there a simple way to make the package compatible across multiple Python versions?

I don’t build anything Python-specific in the package; it simply downloads the precompiled library, places it in the package, and includes an __init__.py file as a ctypes wrapper.

I’m currently using Hatch and uv for packaging, and while I know about tools like cibuildwheel, I’m unsure if I need it since I’m not compiling anything.

Ultimately, I want to package this once and ensure it works seamlessly across older and newer Python versions. Is this achievable, and if so, how?

Here are some details about the project:

Any advice or best practices would be greatly appreciated.

Thanks!

1 Like

If there’s nothing CPython/ABI specific, then it’s probably safe to relax the platform compatibility tags. Based on this issue, hatch lets you do that by defining a custom build hook. Alternatively, you could re-tag the wheels after building using wheel tags.

2 Likes

I can say from experience that cibuildwheel is not your friend for non Python ABI linked wheels.

1 Like

Update:
I created new package using uv. then I put the shared library in the package folder near __init__.py. Added custom hook that set it as pure_python = False and modified tag to something that works across different python versions