Releases: astral-sh/python-build-standalone
20230507
- CPython 3.11.1 -> 3.11.3
- CPython 3.10.9 -> 3.10.11
- pip 22.3.1 -> 23.1.2
- setuptools 65.6.3 -> 67.7.2
- Add ppc64le-unknown-linux-gnu distributions for CPython 3.9, 3.10, and 3.11
- SQLite 3.40.1 -> 3.41.2
- binutils 2.39 -> 2.40
- LLVM 15.0.7 -> 16.0.3
Note: the initial upload of this release on 2023-05-07 corrupted the release assets (#172). The assets were re-uploaded on 2023-05-14. This effectively changed the SHA-256 of all assets. We would normally treat releases as immutable. But since the initial release was fully corrupted, we decided to just delete and re-upload the assets.
20230116
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
_readline
extension module linked against readline by default. The full distributions contained a compiled extension variant linked against libedit. - The
_gdbm
extension 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.
_hashlib
metadata inPYTHON.json
no longer advertises a dependency onlibssl
for some distributions.- There is a possibility that
_zlib
linking behavior changed on some distributions as a result of porting extension module metadata to YAML. (89e0952) - The
_testcapi
extension module is now globally disabled. - The
xxlimited
extension module is now globally disabled. --with-dbmliborder
is 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
_decimal
is 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
_elementtree
andpyexpat
extension 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_EXTENSION
is 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.sh
into standalone.patch
files. - Rust dependencies have been updated to latest versions.
build-windows.py
now accepts a--vs
argument 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.py
now accepts a--windows-sdk-version
argument 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.json
referenced object files are present in the tar archive. - Validation code now ensures that all
PYTHON.json
extension 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.json
build metadata. We know the object file annotations are wrong. See #156. It is possible some symbols are present/missing inpython
/libpython
as 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.py
intoconfigure
. This is a good idea. But the port is not yet complete and logic still spansconfigure
andsetup.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 toconfigure
is 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. _dbm
extension module behavior. See 3234e7f for more info.
20221220
Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20221220/running.html.
- CPython 3.8.15 -> 3.8.16
- CPython 3.9.15 -> 3.9.16
- CPython 3.10.8 -> 3.10.9
- readline 8.1.2 -> 8.2
- xz 5.2.6 -> 5.2.9
- sqlite 3.39.4 -> 3.40.0
- setuptools 65.5.1 -> 65.6.3
mkfifoat
andmknodat
are always disabled on Python 3.8 when targeting Apple platforms. Prior versions might have used these syscalls at runtime when compiling against a macOS 13.x SDK, which would result in a segfault at runtime on older macOS machines. Previous releases were not built with macOS 13.x SDK and shouldn't have been impacted by this bug.
20221106
Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20221106/running.html.
- CPython 3.10.7 -> 3.10.8
- CPython 3.9.14 -> 3.9.15
- CPython 3.8.14 -> 3.8.15
- setuptools 65.4.1 -> 65.5.1
- pip 22.2.2 -> 22.3.1
- OpenSSL 1.1.1q -> 1.1.1s
- zlib 1.2.12 -> 1.2.13
- xz 5.2.5 -> 5.2.6
20221002
Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20221002/running.html.
- CPython 3.8.13 -> 3.8.14
- CPython 3.9.13 -> 3.9.14
- CPython 3.10.6 -> 3.10.7
- setuptools 63.2.0 -> 65.4.1
- pip 22.2.1 -> 22.2.2
- SQLite 3.39.2 -> 3.39.4
20220802
Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20220802/running.html.
- CPython 3.10 upgraded from 3.10.5 to 3.10.6.
- pip upgraded from 22.1.2 to 22.2.1.
- setuptools upgraded from 62.6.0 to 63.2.0.
- The
pythonX.Y-config
shell script no longer has its shebang rewritten to use a Python interpreter. (#136) - Documentation added for missing
libcrypt.so.1
(#113) - Initial support for
aarch64-unknown-linux-gnu
Python 3.8 builds. These builds are not very well tested but we're optimistic they work. - OpenSSL upgraded from 1.1.1p to 1.1.1q.
- SQLite upgraded from 3.39.0 to 3.39.2.
- Static libpython library removed from the
install_only
archives. - Python stdlib test modules removed from the
install_only
archives. (These are the stdlib's actual unit tests, not packages likeunittest
related to testing.) Theinstall_only
archives are significantly smaller as a result. (#134)
20220630
Need help choosing which build to use? See documentation at https://gregoryszorc.com/docs/python-build-standalone/20220630/running.html.
- CPython 3.10.4 upgraded to 3.10.5.
- OpenSSL upgraded from 1.1.1o to 1.1.1p.
- SQLite upgraded from 3.38.5 to 3.39.0.
- setuptools upgraded from 62.3.2 to 62.6.0.
- pip upgraded from 21.1.1 to 21.1.2.
- Changed tkinter link settings on macOS to fix a segfault (#132). This fixes a regression from the 20220222 release.
20220528
Need help choosing which build to use? See documentation at https://python-build-standalone.readthedocs.io/en/latest/running.html.
- CPython 3.9.12 upgraded to 3.9.13
- setuptools upgraded from 62.1.0 to 62.3.2
- pip upgraded from 22.0.4 to 22.1.1
- SQLite upgraded from 3.38.3 to 3.38.5
- OpenSSL upgraded from 1.1.1n to 1.1.1o
- SQLite extension loading feature is now enabled
- ncurses and libffi license texts were refreshed to be in sync with their current version. This only effectively changed copyright years.
- readline license is now annotated as
GPL-3.0-only
instead of the deprecatedGPL-3.0
SPDX expression. - Clang toolchains are now downloaded from https://github.com/indygreg/toolchain-tools instead of built from source.
- Documentation updates around target triples and which distributions to use.
20220502
Need help choosing which build to use? See documentation at https://python-build-standalone.readthedocs.io/en/latest/running.html.
- CPython 3.9 upgraded from 3.9.11 to 3.9.12
- CPython 3.10 upgraded from 3.10.3 to 3.10.4
- setuptools upgraded from 60.9.3 to 62.1.0.
- Python 3.8 distributions on macOS no longer use most weakly linked symbols. Previously, CPython weakly linked some symbols only present on macOS 10.10+. (Our x86-64 builds target macOS 10.9.) However, CPython doesn't have proper runtime guards for using the weakly linked symbols until 3.9. If Python attempted to resolve a weakly linked symbol (e.g. by attempting to call a function), the program could crash. This should no longer occur. We believe Python 3.9 and 3.10 correctly handle weakly linked symbols. What this means in practice is our Python 3.8 x86-64 builds should no longer crash when run on older macOS versions. See #122 for more context.
- LLVM/Clang upgraded from 13.0.1 to 14.0.3.
- CPython license file was synchronized from the latest version of 3.10.
- Distributions for Apple targets no longer link against a custom zlib and instead always use the system zlib library. Before, there were multiple copies of zlib being used by these distributions.
- musl libc upgraded from 1.2.2 to 1.2.3.
- SQLite upgraded from 3.38.1 to 3.38.3.
- zlib upgraded from 1.2.11 to 1.2.12.
- Linux and macOS distributions no longer export symbols from dependencies. Previously,
libpython
would export thousands of symbols belonging to dependencies like SQLite and OpenSSL. Another binary loaded into the process could potentially resolve these symbols to the copy inlibpython
. After, these symbols should not be visible/bindable outsidelibpython
and other binaries that use them directly. See #114 for more context. - The Rust code for validating Python distributions has been significantly overhauled. The most notable change is macOS Mach-O binaries now have their symbols validated against macOS SDKs. We now parse
.tbd
YAML files in the macOS SDKs and ensure that every symbol referenced by Mach-O binaries is provided by all macOS versions the binary purports to support. Symbol validation against macOS 10.9 is not performed because its SDK doesn't have TBD files. - Various missing dependencies in the
Makefile
based build system have been fixed. - The Clang toolchain has been put on a diet and no longer includes LLVM projects that we don't utilize. This makes Clang builds faster and smaller.