Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20230116/running.html.
This is a major release compared to recent releases due to a number of changes in order to support Python 3.11. Extended testing of this release during upgrades is encouraged.
- Added CPython 3.11 support and distributions for all supported platforms.
- macOS and non-musl i686 and x86-64 Linux distributions now compiled with LLVM/Clang 15.0.7 instead of 14.0.3. This has the side-effect of introducing DWARF v5 in Linux distributions. #155 is open to consider rolling this back to DWARF v4.
- 3.8 and 3.9 Linux distributions now always link against libedit (02e8695). Before, these 3.8 and 3.9 distributions had their
_readlineextension module linked against readline by default. The full distributions contained a compiled extension variant linked against libedit. - The
_gdbmextension module is now globally disabled (8028229). Before, it was enabled inconsistently on various distributions. - As a consequence of the above 2 changes, all Python distributions are no longer GPL encumbered. Before, the 3.8 and 3.9 Linux and macOS distributions were GPL encumbered due to a dependency on readline and possibly gdbm.
- The definition of extension modules on Linux and macOS distributions is now centrally defined in a YAML file. All extension build instructions and metadata for PYTHON.json is now derived from this file. This teased out subtle inconsistencies with how extension modules are built. Some of these are documented below. Some changes may have eluded the project maintainer's watchful eye. Be on the lookout for subtle changes in extension modules.
_hashlibmetadata inPYTHON.jsonno longer advertises a dependency onlibsslfor some distributions.- There is a possibility that
_zliblinking behavior changed on some distributions as a result of porting extension module metadata to YAML. (89e0952) - The
_testcapiextension module is now globally disabled. - The
xxlimitedextension module is now globally disabled. --with-dbmliborderis now explicitly passed to CPython'sconfigure. This may have impacted with dbm library is used on some distributions. But hopefully any changes won't have a meaningful impact on functionality.- mpdecimal is now built from source (fe9fca0) and
_decimalis now linked against our built libmpdec (40ca5c7). Previously, we used the mpdecimal vendored with and built by CPython. - expat is now built from source (735402c) and the
_elementtreeandpyexpatextension modules now link against our built libexpat (5887123). Previously, we used the expat library vendored with and built by CPython. - iOS builds have been removed from CI. They weren't tested. We weren't releasing them. And the CI builds were only running on CPython 3.9. If iOS (and other Apple OS) support is important to you, please file a GitHub issue so we can discuss how to support these releases.
PY_SQLITE_ENABLE_LOAD_EXTENSIONis now explicit set on all Linux and macOS distributions.- CI now runs verification invoking the built interpreter on Linux where it can. Previously, we only performed the static Rust-based validation on all platforms and the running interpreter tests on macOS and Windows.
- All CPython patches have been factored out of
cpython-unix/build-cpython.shinto standalone.patchfiles. - Rust dependencies have been updated to latest versions.
build-windows.pynow accepts a--vsargument to control which Visual Studio version to use. It defaults to2019(the previous implicit default). But Visual Studio 2022 is known to work.build-windows.pynow accepts a--windows-sdk-versionargument to control which Windows SDK version to use. It defaults to10.0.20348.0(the previous implicit default). Minimal testing has been done to validate that other SDK versions (including Windows 11 SDKs) work.- Duplicate symbol linker warnings are suppressed on Windows static builds. This greatly cuts down on build log spam.
- Validation code now ensures that all
PYTHON.jsonreferenced object files are present in the tar archive. - Validation code now ensures that all
PYTHON.jsonextension module initialization functions are present in binaries. - Fixed macOS aarch64 -> x86_64 cross-compilation (#150).
CPython 3.11 Potential Areas of Concern
Supporting a new major Python release is always a fair amount of work and there are bound to be bugs in the initial release. This section calls out where we think there may be potential for issues with the 3.11 distributions.
PYTHON.jsonbuild metadata. We know the object file annotations are wrong. See #156. It is possible some symbols are present/missing inpython/libpythonas a result of changes to CPython's build system. This area will be iterated on in subsequent releases.- Extension module configuration in general. CPython 3.11 started moving a lot of logic from its
setup.pyintoconfigure. This is a good idea. But the port is not yet complete and logic still spansconfigureandsetup.py. This refactoring was rather invasive to CPython's build system and necessitated a lot of work on our end to work in the new world. Because the port toconfigureis not yet complete, we devised patches to effectively disable a lot of its functionality and continue leveraging our (somewhat hacky) solution of emitting config files and makefile rules explicitly instead of going through the normal mechanisms. All this means extension module building in general is more prone to regressions and unexpected changes than prior Python versions. See 0afdfa0 and commits around it for more specifics. _dbmextension module behavior. See 3234e7f for more info.