bdist_wheel/setuptools如何识别Python版本与平台？解析cp35与py35差异

Great questions—these get to the heart of how Python packaging works with setuptools and PyPI. Let’s break each part down clearly:

1. How setuptools and PyPI determine Python version & platform compatibility #

First, wheel packages follow a standardized filename format defined in PEP 425:
{package_name}-{version}-{python_tag}-{abi_tag}-{platform_tag}.whl

Each segment tells PyPI (and pip) key compatibility info:

• Python tag: Indicates which Python versions the package supports. Examples:
  • py3: Works with any Python 3.x version (all implementations like CPython, PyPy, etc.)
  • cp35: Specific to CPython 3.5 (we’ll cover this more later)
  • py2.py3: Compatible with both Python 2 and 3
• ABI tag: Stands for Application Binary Interface—relevant for packages with compiled extensions. For CPython, this looks like cp35m (the m indicates the "with UCS-2 Unicode" build, though newer versions drop this). For pure Python packages, this is none.
• Platform tag: Shows which OS/architectures the package works on. Examples:
  • any: Pure Python, works on all platforms
  • manylinux1_x86_64: Compatible with most Linux distros on x86_64
  • macosx_10_9_x86_64: macOS 10.9+ on x86_64
  • win_amd64: Windows 64-bit

How setuptools generates these tags: #

• For pure Python packages (no compiled code), setuptools defaults to tags like py3-none-any—meaning it works with any Python 3, no specific ABI, and any platform.
• For packages with compiled extensions (like numpy), setuptools uses your system’s build environment to generate platform-specific tags. For example, compiling on a Linux x86_64 machine would produce a manylinux1_x86_64 platform tag.

How PyPI displays this info: #

PyPI parses the wheel filename’s tags to populate the "Python version" and "Platform" columns on package pages. It also checks the classifiers field in your setup.py (e.g., Programming Language :: Python :: 3.8) to supplement this display.

2. Why mpu and numpy have different compatibility labels #

The difference boils down to whether the package contains compiled code:

• mpu: It’s a pure Python package—all its code is written in Python, no C/C++ extensions. That means it runs the same way on any OS/architecture as long as you have a Python 3 interpreter. So setuptools generates a py3-none-any.whl wheel, and PyPI shows it as compatible with "py3" and no specific platform.
• numpy: It relies heavily on compiled C extensions for performance. These extensions need to be compiled specifically for each OS (Linux/macOS/Windows) and architecture (x86_64/i686). So numpy’s maintainers build multiple wheels for different platforms, each with its own platform tag. PyPI then lists all those supported platforms and architectures on the package page.

Additionally, the setup.py configuration plays a role: mpu’s setup likely only declares Python 3 compatibility via classifiers, while numpy’s setup uses tools (like custom build scripts or cibuildwheel) to generate platform-specific wheels.

3. Is cp35 short for CPython 3.5? And why not use py35? #

Yes! cp35 absolutely stands for CPython 3.5. The difference between cp35 and py35 is:

• py35: A generic tag meaning "works with any Python 3.5 implementation" (CPython, PyPy3.5, Jython 3.5, etc.). Pure Python packages that don’t rely on CPython-specific features might use this.
• cp35: A tag specific to the CPython interpreter. Packages with compiled extensions (like numpy) use this because their C code depends on CPython’s unique C API—these extensions won’t work on other Python implementations like PyPy.

This distinction comes from the PEP 425 specification, which was designed to make it clear whether a package is compatible with all Python implementations or just CPython. Using cp tags ensures that pip doesn’t install a CPython-only package on, say, PyPy, where it would fail to run.

内容的提问来源于stack exchange，提问作者Martin Thoma