Drop Python 2.7
This commit is contained in:
mayeut
@@ -71,7 +71,6 @@ This has been moved to using docker, so you only need the following instructions
|
||||
The dependency update script in the next section requires multiple python versions installed. One way to do this is to use `pyenv`:
|
||||
|
||||
```bash
|
||||
pyenv install 2.7.18
|
||||
pyenv install 3.6.11
|
||||
pyenv install 3.7.8
|
||||
# Optionally add 3.8 and make it the local version;
|
||||
@@ -81,8 +80,6 @@ pyenv install 3.7.8
|
||||
Then, you need to make the required virtual environments:
|
||||
|
||||
```bash
|
||||
$(pyenv prefix 2.7.18)/bin/python -m pip install virtualenv
|
||||
$(pyenv prefix 2.7.18)/bin/python -m virtualenv env27
|
||||
$(pyenv prefix 3.6.11)/bin/python -m venv env36
|
||||
$(pyenv prefix 3.7.8)/bin/python -m venv env37
|
||||
```
|
||||
|
||||
@@ -5,10 +5,6 @@ title: Modern C++ standards
|
||||
Building Python wheels with modern C++ standards (C++11 and later) requires a few tricks.
|
||||
|
||||
|
||||
## Python 2.7 and C++17
|
||||
|
||||
The Python 2.7 header files use the `register` keyword, which is [reserved and unused from C+17 onwards](https://en.cppreference.com/w/cpp/keyword/register). Compiling a wheel for Python 2.7 with the C++17 standard is still possible to allow usage of `register` using proper flag `-Wno-register` for gcc/clang and `/wd5033` for MSVC.
|
||||
|
||||
## manylinux1 and C++14
|
||||
The default `manylinux1` image (based on CentOS 5) contains a version of GCC and libstdc++ that only supports C++11 and earlier standards. There are however ways to compile wheels with the C++14 standard (and later): https://github.com/pypa/manylinux/issues/118
|
||||
|
||||
@@ -27,45 +23,3 @@ To get C++17 support, Xcode 9.3+ is needed, requiring at least macOS 10.13 on th
|
||||
However, if only C++17 compiler and standard template library (STL) features are used (not needing a C++17 runtime) it might be possible to set `MACOSX_DEPLOYMENT_TARGET` to a lower value, such as `"10.9"`. To find out if this is the case, try compiling and running with a lower `MACOSX_DEPLOYMENT_TARGET`: if C++17 features are used that require a more recent deployment target, building the wheel should fail.
|
||||
|
||||
For more details see https://en.cppreference.com/w/cpp/compiler_support, https://en.wikipedia.org/wiki/Xcode, and https://xcodereleases.com/: Xcode 10 needs macOS 10.13 and Xcode 11 needs macOS 10.14.
|
||||
|
||||
## Windows and Python 2.7
|
||||
|
||||
In previous years, Microsoft distributed a compiler toolchain called 'Visual C++ for Python 2.7', which was a distribution of MSVC 2008 that was created to make it easier to build Python 2.7 extensions on Windows, because it was fully compatible with the toolchain that built Python 2.7.
|
||||
|
||||
This toolchain does not support modern C++ standards (i.e., C++11 and later). And it is hard to find this toolchain these days, since Microsoft removed the download for the required Visual Studio 2008 needed to build a native extension in April, 2021. So, by default, cibuildwheel does not attempt to build Python 2.7 extensions on Windows.
|
||||
|
||||
There is an optional workaround, though: the pybind11 project argues and shows that it is [possible to compile Python 2.7 extension with a newer compiler](https://pybind11.readthedocs.io/en/stable/faq.html#working-with-ancient-visual-studio-2008-builds-on-windows) and has an example project showing how to do this: https://github.com/pybind/python_example. The main catch is that a user might need to install [a newer "Microsoft Visual C++ Redistributable"](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads), since the newer C++ standard library's binaries are not included by default with the Python 2.7 installation.
|
||||
|
||||
Forcing `distutils` or `setuptools` to use a more recent version of MSVC that supports modern C++ can be done in the following way:
|
||||
|
||||
1. Set the environment variables `DISTUTILS_USE_SDK=1` and `MSSdk=1`. These two environment variables will tell `distutils`/`setuptools` to not search and set up a build environment that uses Visual C++ for Python 2.7 (aka. MSVC 9).
|
||||
2. Set up the build Visual Studio build environment you want to use, making sure that e.g. `PATH` contains `cl`, `link`, etc.
|
||||
- Usually, this can be done through `vcvarsall.bat x86` or `vcvarsall.bat x64`. The exact location of this file depends on the installation, but the default path for VS 2019 Community (e.g. used in AppVeyor's `Visual Studio 2019` image) is `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat`. **Note**: `vcvarsall.bat` changes the environment variables, so this cannot be run in a subprocess/subshell and consequently running `vsvarsall.bat` in `CIBW_BEFORE_BUILD` does not have any effect.
|
||||
- In Azure Pipelines, [a `VSBuild` task is available](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/visual-studio-build)
|
||||
- In GitHub Actions, the default shell is powershell, so you'll need to use `shell: cmd` to source a `.bat` file, and the directory is `"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat"`. Or you can use an action, such as the [`ilammy/msvc-dev-cmd@v1`](https://github.com/ilammy/msvc-dev-cmd) action to setup the environment (see example below).
|
||||
3. Next, call `cibuildwheel`. Unfortunately, MSVC has separate toolchains for compiling 32-bit and 64-bit, so you will need to run `cibuildwheel` twice: once with `CIBW_BUILD=*-win32` after setting up the `x86` build environment, and once with `CIBW_BUILD=*-win_amd64` in a `x64` environment (see previous step).
|
||||
|
||||
|
||||
**GitHub Action example with ilammy/msvc-dev-cmd**:
|
||||
|
||||
```yaml
|
||||
- uses: ilammy/msvc-dev-cmd@v1
|
||||
|
||||
- name: Build 64-bit wheel
|
||||
run: python -m cibuildwheel --output-dir wheelhouse
|
||||
env:
|
||||
CIBW_BUILD: cp27-win_amd64
|
||||
DISTUTILS_USE_SDK: 1
|
||||
MSSdk: 1
|
||||
|
||||
- uses: ilammy/msvc-dev-cmd@v1
|
||||
with:
|
||||
arch: x86
|
||||
|
||||
- name: Build 32-bit wheel
|
||||
run: python -m cibuildwheel --output-dir wheelhouse
|
||||
env:
|
||||
CIBW_BUILD: cp27-win32
|
||||
DISTUTILS_USE_SDK: 1
|
||||
MSSdk: 1
|
||||
```
|
||||
|
||||
+5
-30
@@ -14,6 +14,10 @@ If your wheel didn't compile, check the list below for some debugging tips.
|
||||
|
||||
- MacOS: calling cibuildwheel from a python3 script and getting a `ModuleNotFoundError`? Due to a (fixed) [bug](https://bugs.python.org/issue22490) in CPython, you'll need to [unset the `__PYVENV_LAUNCHER__` variable](https://github.com/joerick/cibuildwheel/issues/133#issuecomment-478288597) before activating a venv.
|
||||
|
||||
### Building Python 2.7 / PyPy2 wheels
|
||||
|
||||
See the [cibuildwheel verison 1 docs](https://cibuildwheel.readthedocs.io/en/1.x/) for information about building Python 2.7 or PyPy2 wheels. There are lots of tricks and workaround there that are no longer required for Python 3 in cibuildwheel 2.
|
||||
|
||||
### Linux builds on Docker
|
||||
|
||||
Linux wheels are built in the [`manylinux` docker images](https://github.com/pypa/manylinux) to provide binary compatible wheels on Linux, according to [PEP 571](https://www.python.org/dev/peps/pep-0571/). Because of this, when building with `cibuildwheel` on Linux, a few things should be taken into account:
|
||||
@@ -136,35 +140,6 @@ Here's an example GitHub Actions workflow with a job that builds for Apple Silic
|
||||
{% include "../examples/github-apple-silicon.yml" %}
|
||||
```
|
||||
|
||||
### Windows and Python 2.7
|
||||
|
||||
Building 2.7 extensions on Windows is difficult, because the VS 2008 compiler that was used for the original Python compilation was discontinued in 2018, and has since been removed from Microsoft's downloads. Most people choose to not build Windows 2.7 wheels, or to override the compiler to something more modern.
|
||||
|
||||
To override, you need to have a modern compiler toolchain activated, and set `DISTUTILS_USE_SDK=1` and `MSSdk=1`. For example, on GitHub Actions, you would add these steps:
|
||||
|
||||
```yaml
|
||||
- name: Prepare compiler environment for Windows
|
||||
if: runner.os == 'Windows'
|
||||
uses: ilammy/msvc-dev-cmd@v1
|
||||
with:
|
||||
arch: x64
|
||||
|
||||
- name: Set Windows environment variables
|
||||
if: runner.os == 'Windows'
|
||||
shell: bash
|
||||
run: |
|
||||
echo "DISTUTILS_USE_SDK=1" >> $GITHUB_ENV
|
||||
echo "MSSdk=1" >> $GITHUB_ENV
|
||||
|
||||
# invoke cibuildwheel...
|
||||
```
|
||||
|
||||
cibuildwheel will not try to build 2.7 on Windows unless it detects that the above two variables are set. Note that changing to a more modern compiler will mean your wheel picks up a runtime dependency to a different [Visual C++ Redistributable][]. You also need to be [a bit careful][] in designing your extension; some major binding tools like pybind11 do this for you.
|
||||
|
||||
More on setting a custom Windows toolchain in our docs on modern C++ standards [here](cpp_standards.md#windows-and-python-27).
|
||||
|
||||
[Visual C++ Redistributable]: https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0
|
||||
[a bit careful]: https://pybind11.readthedocs.io/en/stable/faq.html#working-with-ancient-visual-studio-2008-builds-on-windows
|
||||
|
||||
### Building packages with optional C extensions
|
||||
|
||||
@@ -206,7 +181,7 @@ python3 -m twine upload wheelhouse/*.whl
|
||||
|
||||
### 'ImportError: DLL load failed: The specific module could not be found' error on Windows
|
||||
|
||||
Visual Studio and MSVC link the compiled binary wheels to the Microsoft Visual C++ Runtime. Normally, these are included with Python, but when compiling with a newer version of Visual Studio, it is possible users will run into problems on systems that do not have these runtime libraries installed. The solution is to ask users to download the corresponding Visual C++ Redistributable from the [Microsoft website](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads) and install it. Since a Python installation normally includes these VC++ Redistributable files for [the version of the MSVC compiler used to compile Python](https://wiki.python.org/moin/WindowsCompilers), this is typically only a problem when compiling a Python 2.7 C extension with a newer compiler, e.g. to support a modern C++ standard (see [the section on modern C++ standards for Python 2.7](cpp_standards.md#windows-and-python-27) for more details).
|
||||
Visual Studio and MSVC link the compiled binary wheels to the Microsoft Visual C++ Runtime. Normally, these are included with Python, but when compiling with a newer version of Visual Studio, it is possible users will run into problems on systems that do not have these runtime libraries installed. The solution is to ask users to download the corresponding Visual C++ Redistributable from the [Microsoft website](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads) and install it. Since a Python installation normally includes these VC++ Redistributable files for [the version of the MSVC compiler used to compile Python](https://wiki.python.org/moin/WindowsCompilers), this is typically only a problem when compiling a Python C extension with a newer compiler.
|
||||
|
||||
Additionally, Visual Studio 2019 started linking to an even newer DLL, `VCRUNTIME140_1.dll`, besides the `VCRUNTIME140.dll` that is included with recent Python versions (starting from Python 3.5; see [here](https://wiki.python.org/moin/WindowsCompilers) for more details on the corresponding Visual Studio & MSVC versions used to compile the different Python versions). To avoid this extra dependency on `VCRUNTIME140_1.dll`, the [`/d2FH4-` flag](https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/) can be added to the MSVC invocations (check out [this issue](https://github.com/joerick/cibuildwheel/issues/423) for details and references).
|
||||
|
||||
|
||||
+15
-20
@@ -120,12 +120,10 @@ When setting the options, you can use shell-style globbing syntax, as per [fnmat
|
||||
|
||||
| | macOS | Windows | Manylinux Intel | Manylinux Other |
|
||||
|--------------|---------------------------------------------------------------------|-------------------------------|-----------------------------------------------|----------------------------------------------------------------------------|
|
||||
| Python 2.7 | cp27-macosx_x86_64 | cp27-win_amd64<br/>cp27-win32 | cp27-manylinux_x86_64<br/>cp27-manylinux_i686 | |
|
||||
| Python 3.6 | cp36-macosx_x86_64 | cp36-win_amd64<br/>cp36-win32 | cp36-manylinux_x86_64<br/>cp36-manylinux_i686 | cp36-manylinux_aarch64<br/>cp36-manylinux_ppc64le<br/>cp36-manylinux_s390x |
|
||||
| Python 3.7 | cp37-macosx_x86_64 | cp37-win_amd64<br/>cp37-win32 | cp37-manylinux_x86_64<br/>cp37-manylinux_i686 | cp37-manylinux_aarch64<br/>cp37-manylinux_ppc64le<br/>cp37-manylinux_s390x |
|
||||
| Python 3.8 | cp38-macosx_x86_64 | cp38-win_amd64<br/>cp38-win32 | cp38-manylinux_x86_64<br/>cp38-manylinux_i686 | cp38-manylinux_aarch64<br/>cp38-manylinux_ppc64le<br/>cp38-manylinux_s390x |
|
||||
| Python 3.9 | cp39-macosx_x86_64<br/>cp39-macosx_universal2<br/>cp39-macosx_arm64 | cp39-win_amd64<br/>cp39-win32 | cp39-manylinux_x86_64<br/>cp39-manylinux_i686 | cp39-manylinux_aarch64<br/>cp39-manylinux_ppc64le<br/>cp39-manylinux_s390x |
|
||||
| PyPy2.7 v7.3 | pp27-macosx_x86_64 | pp27-win32 | pp27-manylinux_x86_64 | |
|
||||
| PyPy3.6 v7.3 | pp36-macosx_x86_64 | pp36-win32 | pp36-manylinux_x86_64 | |
|
||||
| PyPy3.7 v7.3 | pp37-macosx_x86_64 | pp37-win32 | pp37-manylinux_x86_64 | |
|
||||
|
||||
@@ -133,28 +131,30 @@ When setting the options, you can use shell-style globbing syntax, as per [fnmat
|
||||
The list of supported and currently selected build identifiers can also be retrieved by passing the `--print-build-identifiers` flag to cibuildwheel.
|
||||
The format is `python_tag-platform_tag`, with tags similar to those in [PEP 425](https://www.python.org/dev/peps/pep-0425/#details).
|
||||
|
||||
For CPython, the minimally supported macOS version is 10.9; for PyPy 2.7 and PyPy 3.6/3.7, respectively macOS 10.7 and 10.13 or higher is required.
|
||||
For CPython, the minimally supported macOS version is 10.9; for PyPy 3.6/3.7, macOS 10.13 or higher is required.
|
||||
|
||||
See the [cibuildwheel 1 documentation](https://cibuildwheel.readthedocs.io/en/1.x/) for past end of life versions of Python, and PyPy2.7.
|
||||
|
||||
#### Examples
|
||||
|
||||
```yaml
|
||||
# Only build on Python 3.6
|
||||
# Only build on CPython 3.6
|
||||
CIBW_BUILD: cp36-*
|
||||
|
||||
# Skip building on Python 2.7 on the Mac
|
||||
CIBW_SKIP: cp27-macosx_x86_64
|
||||
# Skip building on CPython 3.6 on the Mac
|
||||
CIBW_SKIP: cp36-macosx_x86_64
|
||||
|
||||
# Skip building on Python 3.8 on the Mac
|
||||
# Skip building on CPython 3.8 on the Mac
|
||||
CIBW_SKIP: cp38-macosx_x86_64
|
||||
|
||||
# Skip building on Python 2.7 on all platforms
|
||||
CIBW_SKIP: cp27-*
|
||||
# Skip building on CPython 3.6 on all platforms
|
||||
CIBW_SKIP: cp36-*
|
||||
|
||||
# Skip Python 2.7 on Windows
|
||||
CIBW_SKIP: cp27-win*
|
||||
# Skip CPython 3.6 on Windows
|
||||
CIBW_SKIP: cp36-win*
|
||||
|
||||
# Skip Python 2.7 on 32-bit Windows
|
||||
CIBW_SKIP: cp27-win32
|
||||
# Skip CPython 3.6 on 32-bit Windows
|
||||
CIBW_SKIP: cp36-win32
|
||||
|
||||
# Skip CPython 3.6 and CPython 3.7
|
||||
CIBW_SKIP: cp36-* cp37-*
|
||||
@@ -162,13 +162,9 @@ CIBW_SKIP: cp36-* cp37-*
|
||||
# Skip Python 3.6 on Linux
|
||||
CIBW_SKIP: cp36-manylinux*
|
||||
|
||||
# Only build on Python 3 (ready for 3.10 when it comes) and skip 32-bit builds
|
||||
CIBW_BUILD: {cp,pp}3*-*
|
||||
# Skip 32-bit builds
|
||||
CIBW_SKIP: "*-win32 *-manylinux_i686"
|
||||
|
||||
# Only build PyPy and CPython 3
|
||||
CIBW_BUILD: pp* cp3*-*
|
||||
|
||||
# Disable building PyPy wheels on all platforms
|
||||
CIBW_SKIP: pp*
|
||||
```
|
||||
@@ -489,7 +485,6 @@ Set an alternative Docker image to be used for building [manylinux](https://gith
|
||||
The value of this option can either be set to `manylinux1`, `manylinux2010`, `manylinux2014` or `manylinux_2_24` to use a pinned version of the [official manylinux images](https://github.com/pypa/manylinux) and [PyPy manylinux images](https://github.com/pypy/manylinux). Alternatively, set these options to any other valid Docker image name. For PyPy, only the official `manylinux2010` image is currently available. For architectures other
|
||||
than x86 (x86\_64 and i686) `manylinux2014` or `manylinux_2_24` must be used, because the first version of the manylinux specification that supports additional architectures is `manylinux2014`.
|
||||
|
||||
Note that `manylinux2014`/`manylinux_2_24` don't support builds with Python 2.7 - when building with `manylinux2014`/`manylinux_2_24`, skip Python 2.7 using `CIBW_SKIP` (see example below).
|
||||
|
||||
If setting a custom Docker image, you'll need to make sure it can be used in the same way as the official, default Docker images: all necessary Python and pip versions need to be present in `/opt/python/`, and the auditwheel tool needs to be present for cibuildwheel to work. Apart from that, the architecture and relevant shared system libraries need to be compatible to the relevant standard to produce valid manylinux1/manylinux2010/manylinux2014/manylinux_2_24 wheels (see [pypa/manylinux on GitHub](https://github.com/pypa/manylinux), [PEP 513](https://www.python.org/dev/peps/pep-0513/), [PEP 571](https://www.python.org/dev/peps/pep-0571/), [PEP 599](https://www.python.org/dev/peps/pep-0599/) and [PEP 600](https://www.python.org/dev/peps/pep-0600/) for more details).
|
||||
|
||||
@@ -544,7 +539,7 @@ here and it will be used instead.
|
||||
If you need different dependencies for each python version, provide them
|
||||
in the same folder with a `-pythonXY` suffix. e.g. if your
|
||||
`CIBW_DEPENDENCY_VERSIONS=./constraints.txt`, cibuildwheel will use
|
||||
`./constraints-python27.txt` on Python 2.7, or fallback to
|
||||
`./constraints-python37.txt` on Python 3.7, or fallback to
|
||||
`./constraints.txt` if that's not found.
|
||||
|
||||
Platform-specific variants also available:<br/>
|
||||
|
||||
@@ -123,8 +123,6 @@ To build Linux, Mac, and Windows wheels on Travis CI, create a `.travis.yml` fil
|
||||
{% include "../examples/travis-ci-minimal.yml" %}
|
||||
```
|
||||
|
||||
Note that building Windows Python 2.7 wheels on Travis is unsupported unless using a newer compiler [via a workaround](cpp_standards.md).
|
||||
|
||||
Commit this file, enable building of your repo on Travis CI, and push.
|
||||
|
||||
Then setup a deployment method by following the [Travis CI deployment docs](https://docs.travis-ci.com/user/deployment/), or see [Delivering to PyPI](deliver-to-pypi.md). For more info on `.travis.yml`, check out the [docs](https://docs.travis-ci.com/).
|
||||
|
||||
Reference in New Issue
Block a user