• pip

    • pip

    PEP 571

    The manylinux2010 Platform Tag

    Abstract

    This PEP proposes the creation of a platform tag to succeed the tag introduced by PEP 513. It also proposes that PyPI and both be updated to support uploading, downloading, and installing distributions on compatible platforms.manylinux2010``manylinux1``pip``manylinux2010

    Rationale

    True to its name, the platform tag has made the installation of binary extension modules a reality on many Linux systems. Libraries like [2] and [3] are more accessible to Python developers now that their installation on common architectures does not depend on fragile development environments and build toolchains.manylinux1``cryptography``numpy

    manylinux1 wheels achieve their portability by allowing the extension modules they contain to link against only a small set of system-level shared libraries that export versioned symbols old enough to benefit from backwards-compatibility policies. Extension modules in a wheel that rely on , for example, must be built against version 2.5 or earlier; they may then be run systems that provide more recent version that still export the required symbols at version 2.5.manylinux1``glibc``glibc

    PEP 513 drew its whitelisted shared libraries and their symbol versions from CentOS 5.11, which was the oldest supported CentOS release at the time of its writing. Unfortunately, CentOS 5.11 reached its end-of-life on March 31st, 2017 with a clear warning against its continued use. [4] No further updates, such as security patches, will be made available. This means that its packages will remain at obsolete versions that hamper the efforts of Python software packagers who use the Docker image.manylinux1

    CentOS 6 is now the oldest supported CentOS release, and will receive maintenance updates through November 30th, 2020. [5] We propose that a new PEP 425-style platform tag called be derived from CentOS 6 and that the toolchain, PyPI, and be updated to support it.manylinux2010``manylinux``pip

    This was originally proposed as , but the versioning has been changed to use calendar years (also known as CalVer [22]). This makes it easier to define future manylinux tags out of order: for example, a hypothetical standard may be defined via a new PEP before , or a standard might be defined that targets systems older than this PEP but newer than .manylinux2``manylinux2017``manylinux2014``manylinux2007``manylinux1

    Calendar versioning also gives a rough idea of which Linux distribution versions support which tag: will work on most distribution versions released since 2010. This is only an approximation, however: the actual compatibility rules are defined below, and some newer distributions may not meet them.manylinux2010

    The manylinux2010 policy

    The following criteria determine a linux wheel’s eligibility for the manylinux2010 tag:

    1. The wheel may only contain binary executables and shared objects compiled for one of the two architectures supported by CentOS 6: x86_64 or i686. [5]

    2. The wheel’s binary executables or shared objects may not link against externally-provided libraries except those in the following whitelist:

      This list is identical to the externally-provided libraries whitelisted for manylinux1, minus libncursesw.so.5 and libpanelw.so.5. [7] libpythonX.Y remains ineligible for inclusion for the same reasons outlined in PEP 513.

      libcrypt.so.1 was retrospectively removed from the whitelist after Fedora 30 was released with libcrypt.so.2 instead.

      On Debian-based systems, these libraries are provided by the packages:

    On RPM-based systems, they are provided by these packages:

    1. If the wheel contains binary executables or shared objects linked against any whitelisted libraries that also export versioned symbols, they may only depend on the following maximum versions:

      As an example, manylinux2010 wheels may include binary artifacts that require glibc symbols at version GLIBC_2.4, because this an earlier version than the maximum of GLIBC_2.12.

    2. If a wheel is built for any version of CPython 2 or CPython versions 3.0 up to and including 3.2, it must include a CPython ABI tag indicating its Unicode ABI. A manylinux2010 wheel built against Python 2, then, must include either the cpy27mu tag indicating it was built against an interpreter with the UCS-4 ABI or the cpy27m tag indicating an interpreter with the UCS-2 ABI. (PEP 3149, [9])

    3. A wheel must not require the PyFPE_jbuf symbol. This is achieved by building it against a Python compiled without the --with-fpectl configure flag.

    PEP 513

    A Platform Tag for Portable Linux Built Distributions

    Abstract

    This PEP proposes the creation of a new platform tag for Python package built distributions, such as wheels, called with external dependencies limited to a standardized, restricted subset of the Linux kernel and core userspace ABI. It proposes that PyPI support uploading and distributing wheels with this platform tag, and that support downloading and installing these packages on compatible platforms.manylinux1_{x86_64,i686}``pip

    Rationale

    Currently, distribution of binary Python extensions for Windows and OS X is straightforward. Developers and packagers build wheels (PEP 427, PEP 491), which are assigned platform tags such as or , and upload these wheels to PyPI. Users can download and install these wheels using tools such as .win32``macosx_10_6_intel``pip

    For Linux, the situation is much more delicate. In general, compiled Python extension modules built on one Linux distribution will not work on other Linux distributions, or even on different machines running the same Linux distribution with different system libraries installed.

    Build tools using PEP 425 platform tags do not track information about the particular Linux distribution or installed system libraries, and instead assign all wheels the too-vague or tags. Because of this ambiguity, there is no expectation that -tagged built distributions compiled on one machine will work properly on another, and for this reason, PyPI has not permitted the uploading of wheels for Linux.linux_i686``linux_x86_64``linux

    It would be ideal if wheel packages could be compiled that would work on any linux system. But, because of the incredible diversity of Linux systems – from PCs to Android to embedded systems with custom libcs – this cannot be guaranteed in general.

    Instead, we define a standard subset of the kernel+core userspace ABI that, in practice, is compatible enough that packages conforming to this standard will work on many linux systems, including essentially all of the desktop and server distributions in common use. We know this because there are companies who have been distributing such widely-portable pre-compiled Python extension modules for Linux – e.g. Enthought with Canopy [4] and Continuum Analytics with Anaconda [5].

    Building on the compatibility lessons learned from these companies, we thus define a baseline platform tag for use by binary Python wheels, and introduce the implementation of preliminary tools to aid in the construction of these wheels.manylinux1``manylinux1

    Key Causes of Inter-Linux Binary Incompatibility

    To properly define a standard that will guarantee that wheel packages meeting this specification will operate on many linux platforms, it is necessary to understand the root causes which often prevent portability of pre-compiled binaries on Linux. The two key causes are dependencies on shared libraries which are not present on users’ systems, and dependencies on particular versions of certain core libraries like .glibc

    External Shared Libraries

    Most desktop and server linux distributions come with a system package manager (examples include on Debian-based systems, on -based systems, and on Arch linux) that manages, among other responsibilities, the installation of shared libraries installed to system directories such as . Most non-trivial Python extensions will depend on one or more of these shared libraries, and thus function properly only on systems where the user has the proper libraries (and the proper versions thereof), either installed using their package manager, or installed manually by setting certain environment variables such as to notify the runtime linker of the location of the depended-upon shared libraries.APT``yum``RPM``pacman``/usr/lib``LD_LIBRARY_PATH

    Versioning of Core Shared Libraries

    Even if the developers a Python extension module wish to use no external shared libraries, the modules will generally have a dynamic runtime dependency on the GNU C library, . While it is possible, statically linking is usually a bad idea because certain important C functions like cannot be called from code that statically links . A runtime shared library dependency on a system-provided is unavoidable in practice.glibc``glibc``dlopen()``glibc``glibc

    The maintainers of the GNU C library follow a strict symbol versioning scheme for backward compatibility. This ensures that binaries compiled against an older version of can run on systems that have a newer . The opposite is generally not true – binaries compiled on newer Linux distributions tend to rely upon versioned functions in that are not available on older systems.glibc``glibc``glibc

    This generally prevents wheels compiled on the latest Linux distributions from being portable.

    The manylinux1 policy

    For these reasons, to achieve broad portability, Python wheels

    To be eligible for the manylinux1 platform tag, a Python wheel must therefore both (a) contain binary executables and compiled code that links only to libraries with SONAMEs included in the following list:

    and, (b) work on a stock CentOS 5.11 [6] system that contains the system package manager’s provided versions of these libraries.

    libcrypt.so.1 was retrospectively removed from the whitelist after Fedora 30 was released with libcrypt.so.2 instead.

    Because CentOS 5 is only available for x86_64 and i686 architectures, these are the only architectures currently supported by the manylinux1 policy.

    On Debian-based systems, these libraries are provided by the packages

    On RPM-based systems, these libraries are provided by the packages

    This list was compiled by checking the external shared library dependencies of the Canopy [4] and Anaconda [5] distributions, which both include a wide array of the most popular Python modules and have been confirmed in practice to work across a wide swath of Linux systems in the wild.

    Many of the permitted system libraries listed above use symbol versioning schemes for backward compatibility. The latest symbol versions provided with the CentOS 5.11 versions of these libraries are:

    Therefore, as a consequence of requirement (b), any wheel that depends on versioned symbols from the above shared libraries may depend only on symbols with the following versions:

    These recommendations are the outcome of the relevant discussions in January 2016 [7], [8].

    Note that in our recommendations below, we do not suggest that pip or PyPI should attempt to check for and enforce the details of this policy (just as they don’t check for and enforce the details of existing platform tags like win32). The text above is provided (a) as advice to package builders, and (b) as a method for allocating blame if a given wheel doesn’t work on some system: if it satisfies the policy above, then this is a bug in the spec or the installation tool; if it does not satisfy the policy above, then it’s a bug in the wheel. One useful consequence of this approach is that it leaves open the possibility of further updates and tweaks as we gain more experience, e.g., we could have a “manylinux 1.1” policy which targets the same systems and uses the same manylinux1 platform tag (and thus requires no further changes to pip or PyPI), but that adjusts the list above to remove libraries that have turned out to be problematic or add libraries that have turned out to be safe.

    libpythonX.Y.so.1

    Note that libpythonX.Y.so.1 is not on the list of libraries that a manylinux1 extension is allowed to link to. Explicitly linking to libpythonX.Y.so.1 is unnecessary in almost all cases: the way ELF linking works, extension modules that are loaded into the interpreter automatically get access to all of the interpreter’s symbols, regardless of whether or not the extension itself is explicitly linked against libpython. Furthermore, explicit linking to libpython creates problems in the common configuration where Python is not built with --enable-shared. In particular, on Debian and Ubuntu systems, apt install pythonX.Y does not even install libpythonX.Y.so.1, meaning that any wheel that did depend on libpythonX.Y.so.1 could fail to import.

    There is one situation where extensions that are linked in this way can fail to work: if a host program (e.g., apache2) uses dlopen() to load a module (e.g., mod_wsgi) that embeds the CPython interpreter, and the host program does not pass the RTLD_GLOBAL flag to dlopen(), then the embedded CPython will be unable to load any extension modules that do not themselves link explicitly to libpythonX.Y.so.1. Fortunately, apache2 does set the RTLD_GLOBAL flag, as do all the other programs that embed-CPython-via-a-dlopened-plugin that we could locate, so this does not seem to be a serious problem in practice. The incompatibility with Debian/Ubuntu is more of an issue than the theoretical incompatibility with a rather obscure corner case.

    This is a rather complex and subtle issue that extends beyond the scope of manylinux1; for more discussion see: [9], [10], [11].

    UCS-2 vs UCS-4 builds

    All versions of CPython 2.x, plus CPython 3.0-3.2 inclusive, can be built in two ABI-incompatible modes: builds using the --enable-unicode=ucs2 configure flag store Unicode data in UCS-2 (or really UTF-16) format, while builds using the --enable-unicode=ucs4 configure flag store Unicode data in UCS-4. (CPython 3.3 and greater use a different storage method that always supports UCS-4.) If we want to make sure ucs2 wheels don’t get installed into ucs4 CPythons and vice-versa, then something must be done.

    所有版本的 CPython 2.x 以及 CPython 3.0-3.2（包括 CPython 3.0-3.2）都可以以两种 ABI 不兼容模式构建：使用 --enable-unicode=ucs2 配置标志构建，以 UCS-2（或真正的 UTF-16）存储 Unicode 数据 ) 格式，同时使用 --enable-unicode=ucs4 配置标志在 UCS-4 中存储 Unicode 数据进行构建。 （CPython 3.3 及更高版本使用始终支持 UCS-4 的不同存储方法。）如果我们想确保 ucs2 wheel不会安装到 ucs4 CPython 中，反之亦然，则必须采取一些措施。

    An earlier version of this PEP included a requirement that manylinux1 wheels targeting these older CPython versions should always use the ucs4 ABI. But then, in between the PEP’s initial acceptance and its implementation, pip and wheel gained first-class support for tracking and checking this aspect of ABI compatibility for the relevant CPython versions, which is a better solution. So we now allow the manylinux1 platform tags to be used in combination with any ABI tag. However, to maintain compatibility it is crucial to ensure that all manylinux1 wheels include a non-trivial abi tag. For example, a wheel built against a ucs4 CPython might have a name like:

    此 PEP 的早期版本要求针对这些旧 CPython 版本的 manylinux1 wheel应始终使用 ucs4 ABI。 但后来，在 PEP 的最初接受和实施之间，pip 和 wheel 获得了一流的支持，可以跟踪和检查相关 CPython 版本的 ABI 兼容性这方面，这是一个更好的解决方案。 因此，我们现在允许 manylinux1 平台标签与任何 ABI 标签结合使用。 然而，为了保持兼容性，确保所有 manylinux1 wheel都包含重要的 abi 标签至关重要。 例如，针对 ucs4 CPython 构建的wheel可能具有如下名称：

    While a wheel built against the ucs2 ABI might have a name like:

    而针对 ucs2 ABI 构建的wheel可能具有如下名称：

    But you should never have a wheel with a name like:

    但你永远不应该拥有一个具有如下名称的wheel：

    This wheel claims to be simultaneously compatible with both ucs2 and ucs4 builds, which is bad.

    We note for information that the ucs4 ABI appears to be much more widespread among Linux CPython distributors.

    这个wheel 声称同时兼容 ucs2 和 ucs4 版本，但这很糟糕。

    我们注意到，ucs4 ABI 在 Linux CPython 发行商中似乎更为广泛。

    fpectl builds vs. no fpectl builds

    All extant versions of CPython can be built either with or without the --with-fpectl flag to configure. It turns out that this changes the CPython ABI: extensions that are built against a no-fpectl CPython are always compatible with yes-fpectl CPython, but the reverse is not necessarily true. (Symptom: errors at import time complaining about undefined symbol: PyFPE_jbuf.) See: [16].

    For maximum compatibility, therefore, the CPython used to build manylinux1 wheels must be compiled without the --with-fpectl flag, and manylinux1 extensions must not reference the symbol PyFPE_jbuf.

    PEP 491

    The Wheel Binary Package Format 1.9

    Abstract

    This PEP describes the second version of a built-package format for Python called “wheel”. Wheel provides a Python-specific, relocatable package format that allows people to install software more quickly and predictably than re-building from source each time.

    A wheel is a ZIP-format archive with a specially formatted file name and the extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Simple wheels can be unpacked onto and used directly but wheels are usually installed with a specialized installer..whl``sys.path

    This version of the wheel specification adds support for installing distributions into many different directories, and adds a way to find those files after they have been installed.

    PEP Deferral

    This PEP is not currently being actively pursued, with Python packaging improvements currently focusing on the package build process rather than expanding the binary archive format to cover additional use cases.

    Some specific elements to be addressed when work on this PEP is resumed in the future:

    Rationale

    Wheel 1.0 is best at installing files into and a few other locations specified by distutils, but users would like to install files from single distribution into many directories – perhaps separate locations for docs, data, and code. Unfortunately not everyone agrees on where these install locations should be relative to the root directory. This version of the format adds many more categories, each of which can be installed to a different destination based on policy. Since it might also be important to locate the installed files at runtime, this version of the format also adds a way to record the installed paths in a way that can be read by the installed software.site-packages

    Details

    Installing a wheel ‘distribution-1.0-py32-none-any.whl’

    Wheel installation notionally consists of two phases:

    In practice, installers will usually extract files directly from the archive to their destinations without writing a temporary directory.distribution-1.0.data/

    File Format

    File name convention

    The wheel filename is .{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl

    For example, is the first build of a package called ‘distribution’, and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture.distribution-1.0-1-py27-none-any.whl

    The last three components of the filename before the extension are called “compatibility tags.” The compatibility tags express the package’s basic interpreter requirements and are detailed in PEP 425.

    Comparison to .egg

    1. Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don’t always have to wait for the packager to catch up.
    2. Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings.
    3. Wheel has a richer file naming convention for today’s multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI.
    4. Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions.
    5. Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0.
    6. Wheel is a reference to the other Python.

    PEP 427

    The Wheel Binary Package Format 1.0

    Abstract

    This PEP describes a built-package format for Python called “wheel”.

    A wheel is a ZIP-format archive with a specially formatted file name and the extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard ‘unzip’ tool while preserving enough information to spread its contents out onto their final paths at any later time..whl

    PEP Acceptance

    This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]

    Rationale

    Python needs a package format that is easier to install than sdist. Python’s sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers.

    Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment.

    Details

    File Format

    File name convention

    The wheel filename is {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl.

    For example, distribution-1.0-1-py27-none-any.whl is the first build of a package called ‘distribution’, and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture. 例如，distribution-1.0-1-py27-none-any.whl是名为“distribution”的包的第一个构建，在任何 CPU 架构上都与 Python 2.7（任何 Python 2.7 实现）兼容，没有 ABI（纯 Python）。

    The last three components of the filename before the extension are called “compatibility tags.” The compatibility tags express the package’s basic interpreter requirements and are detailed in PEP 425. 扩展名之前文件名的最后三个组成部分称为“兼容性标签”。兼容性标签表达了包的基本解释器要求，在PEP 425中有详细说明。

     

    PEP 425

    Compatibility Tags for Built Distributions

    Abstract

    This PEP specifies a tagging system to indicate with which versions of Python a built or binary distribution is compatible. A set of three tags indicate which Python implementation and language version, ABI, and platform a built distribution requires. The tags are terse because they will be included in filenames.

    PEP Acceptance

    This PEP was accepted by Nick Coghlan on 17th February, 2013.

    Rationale

    Today “python setup.py bdist” generates the same filename on PyPy and CPython, but an incompatible archive, making it inconvenient to share built distributions in the same folder or index. Instead, built distributions should have a file naming convention that includes enough information to decide whether or not a particular archive is compatible with a particular implementation.

    Previous efforts come from a time where CPython was the only important implementation and the ABI was the same as the Python language release. This specification improves upon the older schemes by including the Python implementation, language version, ABI, and platform as a set of tags.

    By comparing the tags it supports with the tags listed by the distribution, an installer can make an educated decision about whether to download a particular built distribution without having to read its full metadata.

    Overview

    The tag format is {python tag}-{abi tag}-{platform tag}

    For example, the tag py27-none-any indicates compatible with Python 2.7 (any Python 2.7 implementation) with no abi requirement, on any platform.

    Use

    The wheel built package format includes these tags in its filenames, of the form . Other package formats may have their own conventions.{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl

    Details

    Python Tag

    The Python tag indicates the implementation and version required by a distribution. Major implementations have abbreviated codes, initially: Python 标记指示发行版所需的实现和版本。主要实现有缩写代码，最初：

    Other Python implementations should use sys.implementation.name.

    The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead. PyPy should probably use its own versions here pp18, pp19.

    The version can be just the major version 2 or 3 py2, py3 for many pure-Python distributions.

    Importantly, major-version-only tags like py2 and py3 are not shorthand for py20 and py30. Instead, these tags mean the packager intentionally released a cross-version-compatible distribution.

    A single-source Python 2/3 compatible distribution can use the compound tag py2.py3. See Compressed Tag Sets, below.

    其他 Python 实现应该使用sys.implementation.name。

    版本是py_version_nodot。CPython 没有点，但如果需要，则使用下划线_代替。PyPy 应该在这里使用它自己的版本pp18，pp19。

    对于许多纯 Python 发行版，该版本可以只是主要版本2或3 py2、py3 。

    重要的是，像py2和py3这样的仅主版本标签不是py20和py30的简写。相反，这些标签意味着打包者有意发布了一个跨版本兼容的发行版。

    单源 Python 2/3 兼容发行版可以使用复合标签py2.py3。请参阅下面的压缩标签集。

    ABI Tag

    The ABI tag indicates which Python ABI is required by any included extension modules. For implementation-specific ABIs, the implementation is abbreviated in the same way as the Python Tag, e.g. cp33d would be the CPython 3.3 ABI with debugging.

    The CPython stable ABI is abi3 as in the shared library suffix.

    Implementations with a very unstable ABI may use the first 6 bytes (as 8 base64-encoded characters) of the SHA-256 hash of their source code revision and compiler flags, etc, but will probably not have a great need to distribute binary distributions. Each implementation’s community may decide how to best use the ABI tag.

    ABI 标记指示任何包含的扩展模块都需要哪个 Python ABI。对于特定于实现的 ABI，实现的缩写方式与 Python 标记相同，例如cp33d将是带有调试功能的 CPython 3.3 ABI。

    CPython 稳定的 ABI 是共享库后缀中的abi3 。

    ABI 非常不稳定的实现可能会使用其源代码修订版和编译器标志等的 SHA-256 散列的前 6 个字节（作为 8 个 base64 编码字符），但可能不需要分发二进制分发。每个实现的社区可以决定如何最好地使用 ABI 标签。

    Platform Tag

    The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore . 平台标签只是distutils.util.get_platform()带有所有连字符-和句点。替换为下划线。

    Use

    The tags are used by installers to decide which built distribution (if any) to download from a list of potential built distributions. The installer maintains a list of (pyver, abi, arch) tuples that it will support. If the built distribution’s tag is in the list, then it can be installed.

    It is recommended that installers try to choose the most feature complete built distribution available (the one most specific to the installation environment) by default before falling back to pure Python versions published for older Python releases. Installers are also recommended to provide a way to configure and re-order the list of allowed compatibility tags; for example, a user might accept only the *-none-any tags to only download built packages that advertise themselves as being pure Python.

    Another desirable installer feature might be to include “re-compile from source if possible” as more preferable than some of the compatible but legacy pre-built options.

    This example list is for an installer running under CPython 3.3 on a linux_x86_64 system. It is in order from most-preferred (a distribution with a compiled extension module, built for the current version of Python) to least-preferred (a pure-Python distribution built with an older version of Python):

    安装程序使用这些标签来决定从潜在的构建发行版列表中下载哪个构建发行版（如果有）。安装程序维护一个它将支持的 (pyver, abi, arch) 元组列表。如果构建的发行版的标签在列表中，则可以安装它。

    建议安装程序默认尝试选择功能最完整的构建发行版（最特定于安装环境的发行版），然后再回退到为旧 Python 版本发布的纯 Python 版本。还建议安装人员提供一种方法来配置和重新排序允许的兼容性标签列表；例如，用户可能只接受*-none-any标签来只下载自称是纯 Python 的构建包。

    另一个理想的安装程序功能可能是包括“如果可能的话从源代码重新编译”，这比一些兼容但遗留的预构建选项更可取。

    此示例列表适用于在 linux_x86_64 系统上在 CPython 3.3 下运行的安装程序。它的顺序是从最喜欢（具有已编译扩展模块的发行版，为当前版本的 Python 构建）到最不喜欢（使用旧版本 Python 构建的纯 Python 发行版）：

    1. cp33-cp33m-linux_x86_64
    2. cp33-abi3-linux_x86_64
    3. cp3-abi3-linux_x86_64
    4. cp33-none-linux_x86_64*
    5. cp3-none-linux_x86_64*
    6. py33-none-linux_x86_64*
    7. py3-none-linux_x86_64*
    8. cp33-none-any
    9. cp3-none-any
    10. py33-none-any
    11. py3-none-any
    12. py32-none-any
    13. py31-none-any
    14. py30-none-any

    Sometimes there will be more than one supported built distribution for a particular version of a package. For example, a packager could release a package tagged cp33-abi3-linux_x86_64 that contains an optional C extension and the same distribution tagged py3-none-any that does not. The index of the tag in the supported tags list breaks the tie, and the package with the C extension is installed in preference to the package without because that tag appears first in the list. 有时，对于特定版本的软件包，会有多个受支持的内置发行版。例如，打包者可以发布一个标记为 cp33-abi3-linux_x86_64的包，其中包含一个可选的 C 扩展，而相同的分发标记为 py3-none-any，但没有。受支持的标签列表中的标签索引打破了平局，具有 C 扩展名的软件包优先于未安装的软件包安装，因为该标签首先出现在列表中。

    Supported Versions#

    The latest version of the pip is the only supported version, previous versions should be considered unsupported. Users are encouraged to make regular updates to their version of pip in order to remain supported.

    最新版本的 pip 是唯一受支持的版本，以前的版本应被视为不受支持。 我们鼓励用户定期更新其 pip 版本，以保持支持。

    Python 2 Support

    pip 20.3 was the last version of pip that supported Python 2. Bugs reported with pip which only occur on Python 2.7 will likely be closed as “won’t fix” issues by pip’s maintainers.

    pip 20.3 是支持 Python 2 的最后一个 pip 版本。pip 报告的仅在 Python 2.7 上出现的错误可能会被 pip 的维护者作为“无法修复”的问题而关闭。

    Python Support Policy

    In general, a given Python version is supported until its usage on PyPI falls below 5%. This is at the maintainers’ discretion, in case extraordinary circumstances arise.

    通常，支持给定 Python 版本，直到其在 PyPI 上的使用率低于 5%。如果出现特殊情况，这由维护者自行决定。

    其他

    pip 国内源

    pip offline

    下载离线包

    生成 requirements.txt

    注意：这个会把环境中的所有库都保存下来，配合virtualenv才好用。如果没有virtualenv，这个方法会保存很多多余的库。

    安装离线包

    pip upgrade

    pip脚本中指定了python的版本，多版本python共存时，修改pip脚本指定python版本

    ucs4 & ucs2

    Py_UNICODE

    请注意，UCS2 和 UCS4 Python 版本不兼容二进制。 在编写扩展或接口时请记住这一点。

    cp27m & cp27mu

    如果Python2.7遇到如下错误： ImportError: /usr/lib64/python2.7/site-packages/xxx/xxx.so: undefined symbol: PyUnicodeUCS2_DecodeASCII 说明你的python编译时使用的是UCS4，但是安装了UCS2版本(标志：cp27m)的第三方库，卸载并重新安装UCS4版本(标志：cp27mu)的第三方库即可。

    cp27m是ucs2，cp27mu是ucs4。

    pip & manylinux

    Manylinux TagClient-side pip version required
    manylinux2014pip >= 19.3
    manylinux2010pip >= 19.3
    manylinux1pip >= 8.1.0

    pip & setuptools

    Python 2.7

    Python 3.6

    pip配置

    参考：pip