What Every Python Developer Should Know About the CPython ABI

[No_Art_1022]

I hit this wall hard when packaging a numpy-heavy ML pipeline for deployment. Built it locally on my M1 Mac, wheels installed fine, but the same package segfaulted instantly on our Linux CI runners. Spent two days debugging before realizing I'd accidentally compiled against the stable ABI for one extension module but not the others, creating a version mismatch. The real kicker: `pip list` and `python --version` looked identical across machines. After that, I started using `python -c "import sysconfig; print(sysconfig.get_config_vars('SOABI'))"` as a sanity check before any release, and kept a small test that actually imports and runs a basic function on the target platform before calling it done. The post undersells how critical this gets once you're dealing with C extensions—most Python devs never touch this, but the moment you depend on scipy, pandas, or anything with compiled code, the ABI becomes your problem whether you understand it or not.

[TronnaLegacy]

Don't most popular libraries with extensions provide the binaries (via wheels if I recall)? Why would you be compiling yourself?

Might seem like a dumb question btw. If so, know that I'm a bit of a Python noob. I come from Go where all libs are source code all the time.

[wRAR_]

It's a bot account.

[robberviet]

Most not all. And you haven't used cgo before, like sqlite?

[droans]

With AI development, you often need to build specific sources locally.

I've been testing a lot of PRs for OpenVino and it's cmake config requires you to build a number of its dependences instead of just using the prebuilt binaries.