cibuildwheel VS auditwheel

It doesn't work with any version of the public API, Limited, Stable, or Unstable, because this is not a part of the API. It's more of an application of [Hyrum's Law](https://www.hyrumslaw.com/).

That said, assuming the structures themselves exist on the versions of Python you're targeting in a format compatible with whatever hacking you're doing on them, it's very easy to compile for lots of Python versions using [cibuildwheel](https://github.com/pypa/cibuildwheel) and the rest of the PyPA ecosystem.

I don't think the Limited API is very useful, as a practical matter for the common distribution methods you need the wheel to be built with the target Python version.

pypa/cibuildwheel: https://github.com/pypa/cibuildwheel :

> Example setup: To build manylinux, musllinux, macOS, and Windows wheels on GitHub Actions, you could use this .github/workflows/wheels.yml

> size of wheels you can upload is constrained by PyPi

I feel PyPi is pretty generous with their limits. You can even request more once you hit the ceiling, i think it’s around 60MB [1]. There are some wheels that are crazy large, tensorflow-gpu [2] are around 500MB each. I think there’s discussions out there to try and find ways of alleviating this problem on PyPi.

> difficult to support multiple versions across multiple operating systems, unless you provide a source distribution, which is then…

This can be a problem but I’ve found that recently the problem has improved quite a lot. You can create manylinux wheels for both x86, x64, and arm64 which cover pretty a lot of the Linux distributions using glibc. A musllinux tag was recently added to cover musl based distributions like Alpine. MacOS wheels support both x64, arm64, and can even be a universal2 wheel. Windows is still purely x86 or x64 for now but I’ve seen some people work on arm64 support support in CPython and once that’s in I’m sure PyPi won’t be too far around. There are also some great tools like cibuildwheel [3] that make building and testing these wheels pretty simple.

> Still a nightmare on Windows

I’m actually curious what is a nightmare about Windows. I found that Windows is probably the easiest of all the platforms to build and upload wheels for. You aren’t limited to a tiny subset of system libs, like you are on Linux, and building them is mostly the same process. Probably the hardest thing is ensuring you have tue correct vs build kit installed but that’s not insurmountable.

[1] https://pypi.org/help/#file-size-limit

[2] https://pypi.org/project/tensorflow-gpu/#files

[3] https://github.com/pypa/cibuildwheel

Click set up a workflow yourself to create a custom workflow. We can refer to the examples provided by cibuildwheel.

Hi there! I've recently spent a lot of time figuring out how to distribute tools written in Python as standalone, self-contained executables, that will works on most of the linux distribution without special environment (including python itself). Decided to write this post to share and discuss my approach. I'd be grateful for any feedback and help on that topic! Here are a few simple steps I've come up with to make this trick: 1) This first is very obvious - use special tooling that can make such an executable, like Nuitka, Pyoxidizer, PyInstaller, python-appimage, etc. 2) Build your application against old enough glibc. You can do this using some old Linux distribution or just be setting up such toolchain manually. Its matters for c extensions, tools like nuitka/pyoxidizer and the python itself. 3) Last but not least - don't forget about dependencies and the dependencies of your dependencies. All Python wheels should have either an `any` [platform tag](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/) or one of the [manylinux](https://peps.python.org/pep-0600/) tags that suits your requirements. You can check tags and repair the bad ones with [auditwheel](https://github.com/pypa/auditwheel). But fortunately, in the last 5-10 years, most of the mainstream packages have received manylinux wheels. Of course, there will be issues with PyOxidizer/Nuitka/pyinstaller/etc pitfalls, especially with big projects, so you need some e2e tests in every Linux you want to support. For educational purposes, I made [this little repo](https://github.com/asapelkin/overpackaged). It includes: 1) A sample app with bad dependencies and a C extension. 2) A script to create a 'wheelhouse' with compatible wheels only (`manylinux*` and `any`). 3) Scripts to build executables using Nuitka, PyOxidizer, Appimage, pex. 4) Portability tests (run executables in different linux distros) and performance benchmarks. 5) Readme and Makefile to run any step with single command. It's obviously not a very useful repo, but at least it helped me to explore this topic a little, maybe it could help to demonstrate my approach to the topic.

In a similar vein: Python projects can use `auditwheel` to automatically relocate (fixup RPATHs) and vendor their "system" dependencies, such as a specific version of `zlib` or `libffi`[1].

[1]: https://github.com/pypa/auditwheel

I was using manylinux as it was suggested by its example and it gathered the libraries via auditwheel and included them into the package. Up to my knowledge, there is no way to exclude libraries from the package, because it cannot have external dependencies apart from the predefined list of libraries. The linux_*.whl tags cannot be used on PyPI for binary packages.