The minimum Rust version has been changed from 1.60 to 1.61 to facilitate use of features required by some Rust crates.

Default macOS Python distributions should no longer crash when running tkinter. This fixes a regression introduced in the 0.20 release.

The paths to Python modules when using Python 3.10 is now properly resolved. Before, buggy version string parsing caused various code to look for Python modules in a 3.1 directory instead of 3.10 . (#569, #600).

Changed interpreter initialization logic around sys.meta_path handling to be more resistant to additional entries. If site is imported during interpreter initialization, a .pth file in site-packages could have the side-effect of registering additional entries on sys.meta_path . Before, this could confuse our interpreter initialization code and result in OxidizedFinder not found on sys.meta_path[0] (this should never happen) errors. Our overly strict code is now more tolerant of unknown entries on sys.meta_path and this error should no longer occur. (#602)

Default CPython distributions upgraded. CPython 3.8.13 -> 3.8.15; 3.9.13 -> 3.9.15; 3.10.4 -> 3.10.8. See https://github.com/indygreg/python-build-standalone/releases/tag/20220630 , https://github.com/indygreg/python-build-standalone/releases/tag/20220802 , https://github.com/indygreg/python-build-standalone/releases/tag/20221002 , and https://github.com/indygreg/python-build-standalone/releases/tag/20221106 for additional changes.

PyO3 Rust crate(s) upgraded from 0.16.5 to 0.17.1.

The mechanism for passing custom arguments to the linker for exporting symbols from built executables has transitioned from using .cargo/config files to emitting cargo:rustc-link-arg=FLAG lines from Cargo build scripts. There should be no change in behavior. Generated Rust projects with a .cargo/config overriding rustflags to pass linker arguments can safely delete these lines, as they are no longer necessary.

SETUPTOOLS_USE_DISTUTILS=stdlib is now unconditionally set when invoking Python packaging tools. Previously, it was only set when statically linking libpython. The new behavior ensures that we consistently use the distutils from the Python stdlib and not the distutils in setuptools. The reason for this change was to work around a change in behavior in modern setuptools/distutils resulting in extension module building failing due to new failures resolving the path to Python.h .

The minimum Rust version has been changed from 1.56 to 1.60 to facilitate use of features required by some Rust crates.

The default Python version is 3.10 (instead of 3.9).

Fixed regression in the behavior of various pyoxidizer commands which prevented them from working without specifying any arguments. This regression was introduced in 0.20 with the upgrade of the clap crate to version 3.1. (#523)

PyO3 Rust crates upgraded from 0.16.4 to 0.16.5. The upgrade fixes compatibility issues with Python 3.10 that could lead to runtime crashes or incorrect behavior in many configurations.

Fixed a runtime panic when incorrect attribute assignments were attempted on the PythonExtensionModule , PythonPackageDistributionResource , and PythonPackageResource Starlark types. (#561)

We no longer panic when encountering invalid UTF-8 when reading process output of various python invocations. Previously, invocations of pip , setup.py , and other processes could result in a panic if invalid UTF-8 was emitted. (#579)

Default CPython distributions upgraded from 3.8.12, 3.9.10, and 3.10.2 to 3.8.13, 3.9.13, and 3.10.4, respectively. See additional changes in these distributions at https://github.com/indygreg/python-build-standalone/releases/tag/20220318 , https://github.com/indygreg/python-build-standalone/releases/tag/20220501 , and https://github.com/indygreg/python-build-standalone/releases/tag/20220528 .

The default Python version is now 3.10 (instead of 3.9).

The mechanism for handling software licenses has been overhauled.

The formatting of licenses during building has changed significantly.

Rust licensing information is now dynamically derived at build time rather than derived from a static list. The Rust components with annotated licensing should be more accurate as a result.

PythonExecutable Starlark types now write out a file containing licensing information for software components within the binary. This restores a feature that was dropped in version 0.5. The name of the file (or disabling of the feature) can be controlled via the PythonExecutable.licenses_filename attribute.

A new pyoxidizer rust-project-licensing command for printing licensing information for Rust projects. This can be used to help debug Rust licensing issues or to generate licensing content for any Rust project.

A PythonExecutable.add_cargo_manifest_licensing() Starlark method for registering the licensing information for a Cargo.toml Rust project. This can be used by Rust projects wishing to have their licensing information captured.

Initial support for aarch64-unknown-linux-gnu Python distributions. The distributions are now defined and PyOxidizer should use them when appropriate. However, the distributions aren’t yet well tested. So feedback on their operation via GitHub issues would be appreciated!

aarch64-apple-darwin (Apple M1) now has a default Python 3.8 distribution. This distribution is not very well tested and use of a newer distribution is strongly preferred.

Managed Rust toolchain upgraded from 1.56.1 to 1.61.0.

Starlark PythonInterpreterConfig documentation has been changed to refer to Python Interpreter Configuration Data Structures . The latter is automatically derived from the canonical Rust source code. So the change effectively results in a single, consistent set of documentation for interpreter configuration.

The mechanism for locating the Apple SDK now uses the apple-sdk Rust crate. The new crate work similarly to how our custom logic was working before. But there may be subtle changes in behavior. If you see new build errors related to Apple SDKs in this release, don’t hesitate to create an issue. One notable change is that we will now look for SDKs in all /Applications/Xcode*.app directories. In environments like GitHub Actions, this will result in finding and using the newest installed SDK.

The jemalloc allocator in built binaries has been upgraded to version 5.3.

The auto-generated Rust project created during binary building is now explicitly licensed to the public domain.

Derivation of a custom libpython library archive now sometimes uses pure Rust code instead of calling external processes. There should be no meaningful change in behavior except for build output being more concise.

Auto-generated Rust projects now contain an empty [workspace] table in their Cargo.toml . This enables auto-generated projects to be nested under an existing workspace directory without Cargo complaining. This approach is more robust in the common case where the Rust project isn’t part of a larger workspace.

The pyembed crate will now properly call multiprocessing.spawn.spawn_main() when the multiprocessing auto dispatch function as configured by PythonInterpreterConfig.multiprocessing_start_method is set to spawn . This resolves a TypeError: spawn_main() missing 1 required positional argument: 'pipe_handle' run-time error that would occur in this configuration. (#483)

The pyembed crate better handles errors during interpreter initialization. This fixes a regression to the error handling introduced by the port to PyO3 in version 0.18.0. (#481)

The pyembed::MainPythonInterpreter type is now more resilient against calling into a finalized Python interpreter. Before, calling py_runmain() (possibly via run() ) could result in a segfault in the type’s Drop implementation.

oxidized_importer.OxidizedFinder.find_distributions() now properly normalizes names when performing comparisons. Previously, the specified name was properly normalized but it was compared against un-normalized strings. Both the search and candidate names are now normalized when performing a comparison. This should fix cases where case and other special character differences could result in a distribution not being found. (#488)

A potential crash when importing extension modules from memory on Windows was fixed. The crash could occur due to discrepancy in Python reference counting when multi-phase initialization was used. (#490)

Our patched distutils only sets Py_BUILD_CORE_BUILTIN on Windows. This fixes errors building at least the grpcio package outside of Windows.

When using a modified distutils to install Python packages, the SETUPTOOLS_USE_DISTUTILS=stdlib environment variable is now set. This prevents setuptools from using its vendored copy of distutils and ignoring our modifications. Before this change, packages with extension modules may not have built correctly, resulting in build or run-time errors.

The pyembed::MainPythonInterpreter Rust API for controlling embedded Python interpreters has been refactored. Various methods now take &self instead of &mut self . acquire_gil() and release_gil() have been removed (use with_gil() instead). MainPythonInterpreter instances now release the GIL after initialization. Before, the GIL would be perpetually held by the instance. Consumers that were calling PyEval_SaveThread() to release the GIL to work around this should delete calls to that function, as the GIL is now released automatically. APIs on MainPythonInterpreter will acquire the GIL as necessary. (#500)

Support for Python 3.10 on all previously supported platforms. Python 3.9 is still the default Python version. Target Python 3.10 by passing python_version = "3.10" to the default_python_distribution() Starlark function.

Default Python distributions upgraded from 3.9.7 to 3.9.10. Various library dependencies have also been upgraded. See https://github.com/indygreg/python-build-standalone/releases/tag/20211017 and https://github.com/indygreg/python-build-standalone/releases/tag/20220222 for the full list of changes.

The pyembed::MainPythonInterpreter Rust struct has gained a with_gil() function for executing a function with the Python GIL held.

PyO3 Rust crate upgraded from version 0.14 to 0.16 .

Managed Rust toolchain upgraded from 1.56.0 to 1.56.1.

p12 Rust crate updated to avoid dependency on version yanked from crates.io (version 0.18.0 could not be installed via cargo in some configurations because of this).

PyOxidizer’s documentation is now more isolated from the rest of the projects in the same repository.

The unable to identify deployment target environment variable for macosx (please report this bug) error message seen when attempting to use a too-old macOS SDK has been replaced to automatically assume the use of MACOSX_DEPLOYMENT_TARGET . A warning message that this will possibly lead to build failures is printed. (#414)

Invocation of signtool.exe on Windows now always passes /fd SHA256 by default. Previously, we did not specify /fd unless a signing algorithm was explicitly requested. Newer versions of signtool.exe appear to insist that /fd be specified.

Default Python distributions now properly advertise system library dependencies on Linux and macOS. The older distributions failed to annotate some library dependencies, which could lead to missing symbol errors in some build environments.

Linux default Python distributions no longer utilize the pthread_yield() function, enabling them to be linked against glibc 2.34+, which deprecated the symbol. (#463)

Python .whl resources parsing now ignores directories. Previously, directories may have been emitted as 0-sized resources.

In some pyoxidizer.bzl configurations, an error would occur due to attempting to write a built executable to a directory that doesn’t exist. This should no longer occur. (#447)

The minimum Rust version has been changed from 1.52 to 1.56 to facilitate use of the newest versions of some Rust crates, Rust 2021 edition, and some Cargo features to enhance linker control.

The run-time Rust code for interfacing with the Python interpreter now uses the PyO3 crate instead of cpython . The code port was quite extensive and while we believe all important run-time functionality is backwards compatible, there are possibly subtle differences in behavior. Please file GitHub issues to report any undesired changes in behavior.

Development workflows relying on specifying the PYTHON_SYS_EXECUTABLE environment variable have changed to use PYO3_PYTHON , as the environment variable has changed between the cpython and pyo3 crates.

The pyembed crate no longer has cpython-link-unresolved-static and cpython-link-default Cargo features. Autogenerated Rust projects also no longer have cpython-link-unresolved-static and cpython-link-default features (which existed as proxies to these features in the pyembed crate).

The pyoxidizer add command has been removed because it didn’t work as advertised.

The pyembed crate no longer has build-mode-* features and its build script no longer attempts to integrate with PyOxidizer or its build artifacts.

The pyembed crate no longer annotates a links entry.

The mechanism by which auto-generated Rust projects integrate with the pyembed crate has changed substantially. If you had created a standalone Rust project via pyoxidizer init-rust-project , you may wish to create a fresh project and reconcile differences in the auto-generated files to ensure things now build as expected.

Default Python distributions on macOS aarch64 are now built with macOS SDK 11.3. macOS x86_64 are now built with macOS SDK 11.1.

Default Python distributions upgraded from 3.8.11 and 3.9.6 to 3.8.12 and 3.9.7. Various library dependencies have also been upgraded. See https://github.com/indygreg/python-build-standalone/releases/tag/20211012 and https://github.com/indygreg/python-build-standalone/releases/tag/20211017 for the full list of changes.

When in verbose mode, messages will be printed displaying the actual result of every request to add a resource. Before, the Starlark code would emit a message like adding extension module foo before requesting the addition and the operation could no-op. This behavior was misleading and hard to debug since it often implied a resource was added when in fact it wasn’t! The new behavior is for the resource collector to tell its callers exactly what actions it took and for the actual results to be displayed to the end-user. This should hopefully make it easier to debug issues with how resources are added to binaries.

A new pyoxidizer generate-python-embedding-artifacts command that writes out file artifacts useful for embedding Python in another project. The command essentially enables other projects to use PyOxidizer’s embeddable Python distributions without using PyOxidizer to build them. See Generic Python Embedding in Rust Applications for documentation.

When Apple SDKs are found via the SDKROOT environment variables, a hard error now occurs if that SDK does not support the target platform or deployment target. Previously, we would allow the use of the SDK, only to likely encounter a hard-to-debug compile error. If the SDKs version does not meet the desired minimum version, a warning message is printed but the build proceeds. (#431)

The pyembed crate (which built binaries use to interface with an embedded Python interpreter) now uses the pyo3 crate instead of cpython to interface with Python APIs.

Nightly Cargo features are no longer required on Windows. (Courtesy of PyO3 giving us complete control over how Python is linked.)

The mechanism by which built binaries link against libpython has been significantly refactored. Before, the cpython crate would link against a partial libpython in many configurations and the pyembed crate would complete the linking with a library defined by PyOxidizer. With the PyO3 crate supporting a configuration file to configure all attributes of linking, the PyO3 crate now fully links against libpython and pyembed doesn’t care about linking libpython at all.

The pyembed crate is now generic and no longer attempts to integrate with pyoxidizer or its build artifacts. The crate can now be used by any Rust application wishing to embed a Python interpreter.

The oxidized_importer Python extension has been extracted from the pyembed crate and is now defined in the python-oxidized-importer crate. The pyembed crate now depends on this crate to provide the custom importer functionality.

Previous versions of PyOxidizer would not build on Rust 1.56+ due to incompatibilities with an older version of the starlark crate. The crate was upgraded to version 0.3.2 to fix this issue.

Managed Rust toolchain upgraded from 1.54.0 to 1.56.0.

The minimum Rust version has been changed from 1.46 to 1.52 to facilitate use of const generics and some other stabilized APIs.

starlark_tugger.PythonWheelBuilder.write_to_directory() now interprets relative paths as relative to the currently configured build path, not relative to the process’s current working directory.

Various Starlark types now ensure that they cannot get out of sync when cloned. Previously, various Starlark types would clone their underlying Rust struct when the Starlark value was cloned. This could cause Starlark value instances to become out of sync with each other if one value was mutated. Now, all mutable Starlark types should hold a reference to a shared resource, ensuring that cloned Starlark values all refer to the same instance. This change could result in Starlark configuration files behaving differently. For example, before you could mutate a value in a function call and that mutation wouldn’t be reflected in the caller’s Starlark value. Now, it would be.

oxidized_importer.OxidizedFinder will now automatically call multiprocessing.set_start_method() when it imports the multiprocessing module. Applications that explicitly call multiprocessing.set_start_method() may fail with RuntimeError("context has already been set") as a result of this change. See Using the multiprocessing Python Module for workarounds.

PythonInterpreterConfig.sys_frozen now defaults to True instead of False .

starlark_tugger.WiXInstaller , starlark_tugger.WiXMSIBuilder , and starlark_tugger.WiXBundleBuilder instances now always default to building an installer for the x64 WiX architecture. Previously, the default architecture would be derived from the architecture of the running binary.

starlark_tugger.WiXMSIBuilder instances no longer have a target_triple attribute.

The default target triple is now derived from the target triple of the running binary, not the environment the running binary was built in. In many cases these would be identical. However, they would diverge if the binary was cross-compiled.

The default Python packaging policy now disables bytecode generation for various modules in the Python standard library in the lib2to3.tests and test packages that contain invalid Python 3 source code and would fail to compile to bytecode. This should enable Python resources to compile without error when setting PythonPackagingPolicy.include_test to True , without requiring a custom resource handling callback to disable bytecode generation. (#147)

Applications with hyphens ( - ) in their name now build properly on Windows. Previously, there would be a cryptic build failure when running rc.exe . (#402)

The ELF (read: Linux) binaries in the default Python distributions have changed how they perform dynamic library loading so they should always pick up the libpython from the distribution. Before, LD_LIBRARY_PATH environment variables could result in the wrong libpython being loaded and errors like ModuleNotFoundError: No module named '_posixsubprocess' being encountered. (#406)

Default Python distributions upgraded from 3.8.10 and 3.9.5 to 3.8.11 and 3.9.6. Various library dependencies have also been upgraded. See https://github.com/indygreg/python-build-standalone/releases/tag/20210724 for the full list of changes.

oxidized_importer.OxidizedFinder now calls multiprocessing.set_start_method() when the multiprocessing module is imported. The behavior of this feature can be controlled via the new PythonInterpreterConfig.multiprocessing_start_method attribute. On macOS, the default start method is effectively switched from spawn to fork , as PyOxidizer supports this mode. The main execution routine of built executables also now recognizes the signatures of processes spawned for multiprocessing use and will automatically function accordingly. This behavior can be disabled via PythonInterpreterConfig.multiprocessing_auto_dispatch . These changes mean that multiprocessing should just work when default settings are used. See Using the multiprocessing Python Module for full documentation of multiprocessing interactions with PyOxidizer.

The oxidized_importer.OxidizedFinder.pkg_resources_import_auto_register now exposes whether the oxidized_importer.OxidizedFinder instance will automatically register itself with pkg_resources .

starlark_tugger.AppleUniversalBinary has gained the starlark_tugger.AppleUniversalBinary.write_to_directory() method.

starlark_tugger.FileContent has gained the starlark_tugger.FileContent.write_to_directory() method.

starlark_tugger.MacOsApplicationBundleBuilder has gained the starlark_tugger.MacOsApplicationBundleBuilder.write_to_directory() method.

starlark_tugger.WiXInstaller has gained the starlark_tugger.WiXInstaller.to_file_content() and starlark_tugger.WiXInstaller.write_to_directory() methods.

starlark_tugger.WiXMSIBuilder has gained the starlark_tugger.WiXMSIBuilder.to_file_content() and starlark_tugger.WiXMSIBuilder.write_to_directory() methods.

starlark_tugger.WiXBundleBuilder has gained the starlark_tugger.WiXBundleBuilder.to_file_content() and starlark_tugger.WiXBundleBuilder.write_to_directory() methods.

starlark_tugger.WiXInstaller has gained the starlark_tugger.WiXInstaller.arch attribute to retrieve and modify the architecture of the WiX installer being built.

The constructors for starlark_tugger.WiXInstaller , starlark_tugger.WiXMSIBuilder , and starlark_tugger.WiXBundleBuilder now accept an arch argument to control the WiX architecture of the installer.

starlark_tugger.WiXMSIBuilder has gained the starlark_tugger.WiXMSIBuilder.arch attribute to define the architecture of the WiX installer being built.

Managed Rust toolchain upgraded from 1.52.0 to 1.54.0.

Visual C++ Redistributable installers upgraded from version 14.28.29910 to 14.29.30040.

The Rust build environment now always sets RUSTC to the path to the Rust compiler that we’ve detected. This should hopefully prevent could not execute process `rustc... errors in environments where Rust is not otherwise installed.

Pre-release pyoxidizer binaries built in CI should now generate Cargo.lock files in Rust projects that work with cargo build --frozen .

Managed Rust toolchains now properly install the Rust stdlib for cross-compiles. Previously, the logs said it was installing them but didn’t actually, leading to build failures due to an incomplete Rust toolchain.

The file modified times in files extracted from Python distributions are now set to the current time. Previously, we preserved the mtime in the tar archive and the Windows archives had an mtime of the UNIX epoch. This could lead to runtime errors in pip due to pip attempting to create a zip file of itself and Python’s zip file code not supporting times older than 1980. If you see a ValueError: ZIP does not support timestamps before 1980 error when running pip as part of running PyOxidizer, you are hitting this bug. You will need modernize the mtimes in the extracted Python distributions. The easiest way to do this is to clear PyOxidizer’s Python distribution cache via pyoxidizer cache-clear .

MSI installers built with starlark_tugger.WiXMSIBuilder should now properly update the PATH environment variable if that installation option is active. This affects PyOxidizer’s own MSI installers.

The new starlark_tugger.PythonWheelBuilder type can be used to create Python wheel ( .whl ) files. It is currently rather low-level and doesn’t have any integrations with other Starlark Python types. But it does allow you to create Python wheels from file content. PyOxidizer uses the type for building its own wheels (previously it was using maturin ).

When building for Apple platforms, we now check for a compatible Apple SDK earlier during binary building (when compiling a custom config.c for a custom libpython ). This should surface missing dependencies sooner in the build and potentially replace cryptic compiler error messages with an actionable one about the Apple SDK. Related to this, we now target a specific Apple SDK when compiling the aforementioned source file to ensure that the same, validated SDK is consistently used.

The order of the content and path arguments to starlark_tugger.MacOsApplicationBundleBuilder.add_macos_file() and starlark_tugger.MacOsApplicationBundleBuilder.add_resources_file() has been reversed and path now defaults to None . While technically a backwards incompatible change, the old methods weren’t usable in prior versions of PyOxidizer because the starlark_tugger.FileContent Starlark type couldn’t be instantiated!

starlark_tugger.FileManifest now performs path normalization and checking on every insertion. Before, there were a few code paths that may have skipped this step, causing bad paths to be inserted.

Tracked paths in starlark_tugger.FileManifest should now have Windows-style directory separators ( \ ) normalized to UNIX style ( / ).

Apple code signatures using a time-stamp server now validate Apple’s code signature checks. Previously, they failed validation due the time-stamped data being incorrect.

The WiX XML IDs and GUIDs in autogenerated .wxs files corresponding to install files were sometimes internally inconsistent or duplicated, leading to malformed .wxs files being generated. Autogenerated .wxs files should now hopefully be well-formed.

Release artifacts should now reference the pyembed crate from the package registry instead of a Git URL. Previously, auto-generated Rust projects might insist the pyembed crate was available at a Git URL. This would disagree with the auto-generated Cargo.lock file and result in a build failure due to building with cargo build --frozen .

Default Python distributions upgraded from 3.8.9 and 3.9.4 to 3.8.10 and 3.9.5.

PyOxidizer releases are now published as pre-built binary wheels to PyPI and can be installed via pip install pyoxidizer .

Apple code signatures now include a time-stamp token issued by Apple’s time-stamp server by default. Presence of the time-stamp token in code signatures is a requirement to notarize applications.

It is now possible to add code signatures to Mach-O binaries that don’t have an existing signature. Previously, it was only possible to sign binaries that had an existing signature.

The starlark_tugger.FileContent Starlark type can now be constructed from filesystem paths or string content via starlark_tugger.FileContent.__init__() . The type also exposes mutable attributes starlark_tugger.FileContent.executable and starlark_tugger.FileContent.filename to view and change instance state.

The new starlark_tugger.FileManifest.add_file() method can be used to add a starlark_tugger.FileContent to a starlark_tugger.FileManifest . The method allows controlling the destination path within the starlark_tugger.FileManifest . Combined with the introduction of starlark_tugger.FileContent.__init__() , it is now possible to add arbitrary file-based or string-based files to a starlark_tugger.FileManifest .

The new starlark_tugger.FileManifest.paths() method can be used to retrieve the paths currently tracked by a starlark_tugger.FileManifest .

The new starlark_tugger.FileManifest.get_file() method can be used to retrieve a starlark_tugger.FileContent from a path in starlark_tugger.FileManifest . The new starlark_tugger.FileManifest.remove() method can be used to remove a tracked path from a starlark_tugger.FileManifest . The new methods unlock the ability to mutate the contents of starlark_tugger.FileManifest instances.

Starlark now has a starlark_tugger.AppleUniversalBinary type that can be used to construct universal / fat / multi-architecture Mach-O binaries, the binary executable format used by Apple operating systems. Starlark primitives like PythonExecutable can today only yield a single architecture binary. However, with the new type, it is possible to take multiple source binaries and combine them into a universal binary, all from Starlark.

The starlark_tugger.WiXInstaller Starlark type now exposes mutable attributes starlark_tugger.WiXInstaller.install_files_root_directory_id and starlark_tugger.WiXInstaller.install_files_wxs_path to control the autogenerated .wxs file containing fragment for install files . See the type’s documentation for more.

starlark_tugger.WiXInstaller.build() now automatically materializes and builds a .wxs file containing fragments for files registered for installation. Before, this Starlark type was not very usable without this file, as WiX wouldn’t pick up files that had been registered for install.

Rust 1.52.0 is now used as the default Rust toolchain (from version 1.51.0).

The musl libc linked default Python distributions no longer use the reallocarray() symbol, which was introduced in musl libc 1.2.2. This should enable musl libc builds to work with musl 1.2.1 and possibly older versions.

PyOxidizer no longer uses the system’s installed Rust toolchain when building projects. By default, it will download and use a specific version of the Rust toolchain. See Managed Rust Toolchain for instructions on disabling this behavior.

The pyembed crate now always canonicalizes the path to the current executable. Previously, if OxidizedPythonInterpreterConfig.exe were set, it would not be canonicalized. It is possible this could break use cases where the current executable is deleted after the executable starts. In this case, the Python interpreter will fail to initialize. If this functionality is important to you, file a feature request.

The pyembed crate will now remove entries from sys.path_hooks related to filesystem importers if filesystem importing is disabled. Previously, only sys.meta_path would have its filesystem importers removed.

The pyembed crate now always registers the oxidized_importer.OxidizedFinder path hook on sys.path_hooks when an instance is being installed on sys.meta_path . This ensures that consumers of sys.path_hooks outside the module importing mechanism (such as pkgutil and pkg_resources ) can use the path hook.

The pyembed crate now registers the oxidized_importer.OxidizedFinder path hook as the 1st entry on sys.path_hooks , not the last.

The oxidized_importer.OxidizedFinder path hook is now more strict about the path values it will respond to. Previously, it would accept str , bytes , pathlib.Path , or any other path-like type. Now, it only responds to str values. Furthermore, it will only respond to values that exactly match oxidized_importer.OxidizedFinder.path_hook_base_str or a well-formed virtual sub-directory thereof. Previously, it would attempt to canonicalize path strings, taking into account the current working directory, filesystem links, and other factors affecting path normalization. The new implementation is simpler and by being stricter should be less brittle at run-time. See Paths Hooks Compatibility for documentation on the path hooks behavior.

The pyembed crate has prefixed all its allocator features ( jemalloc , mimalloc , and snmalloc ) with allocator- . This makes the names consistent with the features in auto-generated Rust projects.

Rust projects created with pyoxidizer init-rust-project no longer fail to build due to a cryptic writing packed resources error.

When materializing Python package distribution resources (i.e. files in .dist-info and .egg-info directories) to the filesystem, package names are now normalized to lowercase with hyphens replaced with underscores. The new behavior matches expectations of official Python resource handling APIs like importlib.metadata . Before, APIs like importlib.metadata would fail to find files materialized by PyOxidizer for package names containing a hyphen or capital latter. (#394)

PyOxidizer now automatically downloads and uses a Rust toolchain at run time. This means there is no longer an install requirement of having Rust already available on your system (unless you install PyOxidizer from source). See Managed Rust Toolchain for details of the new feature, including directions on how to disable the feature and have PyOxidizer use an already installed Rust.

oxidized_importer.OxidizedFinder now supports pkg_resources integration. Most of the pkg_resources APIs are implemented, enabling most pkg_resources functionality to work. pkg_resources integration is automatically enabled upon import of the pkg_resources module, so pkg_resources integration should just work for many applications. See Support for pkg_resources for the full documentation, including which features aren’t implemented.

oxidized_importer.OxidizedFinder now exposes the properties oxidized_importer.OxidizedFinder.path_hook_base_str and oxidized_importer.OxidizedFinder.origin .

Starlark configuration files can now produce macOS Application Bundles. See :py:class`starlark_tugger.MacOsApplicationBundleBuilder` for the API documentation.

pyoxidizer commands that evaluate Starlark files now accept the arguments --var and --var-env to define extra variables to define in the evaluated Starlark file. This enables Starlark files to be parameterized based on explicit strings provided via --var or through the content of environment variables via --var-env .

PyOxidizer can now automatically add cryptographic code signatures when running. This feature is extensively documented at Code Signing . From a high-level, you instantiate and activate a starlark_tugger.CodeSigner in your Starlark configuration to define your code signing certificate. As files are processed as part of evaluating your Starlark configuration file, they are examined for the ability to be signed and code signing is automatically attempted. We support signing Windows files using Microsoft’s official signtool.exe application and Apple Mach-O and bundle files using a pure Rust reimplementation of Apple’s code signing functionality. This functionality is still in its early stages of development and is lacking some power user features to exert low-level control over code signing. Please file feature requests as you encounter limitations with the functionality!

The new Starlark functions starlark_tugger.prompt_confirm() , starlark_tugger.prompt_input() , starlark_tugger.prompt_password() , and starlark_tugger.can_prompt() can be used to allow configuration files to perform interaction with the user via the terminal. The functions all allow a default value to be provided, enabling them to be used in scenarios when stdin isn’t connected to a TTY and can’t be prompted.

The Python API for the oxidized_importer Python extension module providing our custom importer logic is now centrally documented instead of spread out over multiple documentation pages. See API Reference for the new docs. Various type references throughout the generated documentation should now link to the new API docs.

The Starlark dialect is now documented as native Python classes and functions using Sphinx’s support for doing so. The documentation should now look more familiar to Python developers familiar with Sphinx for Python API documentation.

PyOxidizer now stores persistent artifacts (like Rust toolchains) and downloaded Python distributions) in a per-user cache directory. See Cache Directory for more.

The pyoxidizer CLI now accepts --verbose as a sub-command argument. Previously, it was only accepted as an argument before the sub-command name.

Generated Rust projects (which can be temporary as part of building binaries) now contain a Cargo.lock file and are built with cargo build --locked . The template of the Cargo.lock is static and under version control. The presence of the Cargo.lock coupled with cargo build --locked should ensure that Rust crate versions used by Rust projects exactly match those used by the build of PyOxidizer that produced the project. This should result in more deterministic builds and higher reliability of build success.

The 0.13.0 release contained improper crate paths in Cargo.toml files due to a bug in our automated release mechanism. This release should fix those issues.

WiXSimpleMsiBuilder now properly writes XML when a license file is provided.

WixBundleInstallerBuilder now handles the already installed exit code from the VC++ Redistributable installer as a success condition. Previously, installs would abort.

WixBundleInstallerBuilder no longer errors on a missing build directory when attempting to download the Visual C++ Redistributable runtime files.

Per-platform Windows MSI and multi-platform Windows exe installers for PyOxidizer are now available. The installers are built with PyOxidizer, using its built-in support for producing Windows installers.

Default CPython distributions upgraded from 3.9.3 to 3.9.4.

Default Python distributions upgraded setuptools from 54.2.0 to 56.0.0.

The minimum Rust version has been changed from 1.45 to 1.46 to facilitate use of const fn .

On Apple platforms, PyOxidizer now validates that the Apple SDK being used is compatible with the Python distribution being used and will abort the build if not. Previously, PyOxidizer would blindly use whatever SDK was the default and this could lead to cryptic error messages when building (likely undefined symbol errors when linking). The current default Python distributions impose a requirement of the macosx10.15+ SDK for Python 3.8 and macosx11.0+ for Python 3.9. See issue #373 for a comprehensive discussion of this topic.

On Apple platforms, binaries built with PyOxidizer now automatically target the OS version that the Python distribution was built to target. Previously, binaries would likely target the OS version of the building machine unless explicit action was taken. The practical effect of this change is binaries targeting x86_64 should now work on macOS 10.9 without any end-user action required.

Documentation URLs for PyOxidizer now all consistently begin with pyoxidizer_ . Many old documentation URLs no longer work.

The autogenerated pyoxidizer.bzl correctly references the no-copyleft extension module filter instead of the old no-gpl value.

Linux binaries using the libedit variant of the readline Python extension (occurs when using the no-copyleft extension module filter) no longer encounter an undefined symbol error when linking. (#376)

The ctypes extension was previously compiled incorrectly, leading to run-time errors on various platforms. These issues should be fixed.

On Apple platforms, PyOxidizer now automatically locates, validates, and uses an appropriate SDK given the settings of the Python distribution being used. PyOxidizer will reject building with an SDK older than the one used to produce the Python distribution. PyOxidizer will automatically use the newest installed SDK compatible with the target configuration. The SDK and targeting information is printed during builds. See Build Machine Requirements for details on how to override default behavior.

OxidizedFinder now implements path_hook() and a path hook is automatically registered on sys.path_hooks during interpreter initialization when an OxidizedFinder is being used. Feature contributed by William Schwartz in #343.

The snmalloc allocator now uses the C API directly and avoids going through an allocation tracking layer, improving the performance of this allocator. Improvement contributed by Ryan Clanton.

Python distributions updated to latest versions. Changes include: macOS Python 3.8 is now built against the 10.15 SDK instead of 11.1; musl libc upgraded to 1.2.2; setuptools upgraded to 54.2.0; LibreSSL upgraded to 3.2.5; OpenSSL upgraded to 1.1.1k; SQLite upgraded to 3.35.4.

The default Python distribution is now CPython 3.9 instead of 3.8. To use 3.8, pass the python_version="3.8" argument to default_python_distribution() in your configuration file. We don’t anticipate dropping support for 3.8 any time soon. However, this may be necessary in order to more easily support new Python features.

The Python 3.8 distributions no longer support Windows 7 and require Windows 8, Windows 2012, or newer. The Python 3.9 distributions already required these Windows versions.

The minimum Rust version has been changed from 1.41 to 1.45 to facilitate the use of procedural macros.

The pyembed::MainPythonInterpreter::run_as_main() method has been renamed to py_runmain() to reflect that it always calls Py_RunMain() .

The py-module-names file is no longer written as part of the files comprising an embedded Python interpreter.

OxidizedFinder.__init__() no longer accepts resources_data and resources_file argument to specify the resources to load. Instead, call one of the new index_* methods on constructed instances.

OxidizedFinder.__init__() no longer automatically indexes builtin extension modules and frozen modules. Instead, you must now call one of the index_* methods to index these resources.

The pyembed::OxidizedPythonInterpreterConfig.packed_resources field is now a Vec<pyembed::PackedResourcesSource> instead of Vec<&[u8]> . The new enum allows specifying files as alternative resources sources.

The no-gpl value of PythonPackagingPolicy.extension_module_filter has been changed to no-copyleft and it operates on the SPDX license annotations instead of a list we maintained.

show_alloc_count has been removed from types representing Python interpreter configuration because support for this feature was removed in Python 3.9.

pyembed::MainPythonInterpreter.acquire_gil() ’s signature has changed, now returning a Python value directly without wrapping it in a Result .

pyembed::OxidizedPythonInterpreterConfig had its memory allocator fields refactored to support new features and to help prevent bad configs (like defining multiple custom memory allocators).

The Starlark PythonInterpreterConfig.raw_allocator field has been renamed to allocator_backend . The system value has been renamed to default .

The pyembed crate now canonicalizes the current executable’s path and uses this canonicalized path when resolving values with $ORIGIN in them. Previously, the path passed into the program was used without resolving symlinks, etc. If that path were a symlink or hardlink, unexpected results could ensue.

OxidizedFinder.find_distributions() now returns an iterator of OxidizedDistribution instead of a list . Code in the standard library of older versions of CPython expected an iterator to be returned and the new behavior is more compatible. This change enables importlib.metadata.metadata() to work with OxidizedFinder .

Escaping of string and path values when emitting Rust code for the embedded Python interpreter configuration should now be more robust. Previously, special characters (like \ ) were not escaped properly. (#321)

The load() Starlark function should now work. (#328)

pyembed::OxidizedPythonInterpreterConfig.argv is now always used when set, even if self.interpreter_config.argv is also set.

OxidizedFinder now normalizes trailing .__init__ in module names to be equivalent to the parent package to partially emulate CPython’s behavior. See Support for __init__ in Module Names for more. (#317)

The lifetime of pyembed::MainPythonInterpreter.acquire_gil() ’s return value has been adjusted so the Rust compiler will refuse to compile code that could crash due to attempting to use a finalized interpreter. (#345)

pyembed::MainPythonInterpreter.py_runmain() ’s signature has changed, now consuming ownership of the receiver. Subsequent borrows of self now fail to compile rather than causing runtime errors.

The optional rust memory allocator is now thread-safe. Previously, it wasn’t and releasing of the GIL could lead to memory corruption and crashes.

OxidizedResourceCollector.oxidize() should now properly clean up the temporary directory it uses during execution. Before, premature Python interpreter termination (such as during failing tests) could cause the temporary directory to not be removed. Closes #346. Fix contributed by William Schwartz in #347.

OxidizedFinder.find_distributions() now properly handles the default/empty Context instance (specifically instances where .name = None ). Previously, name = None would filter as if .name = "None" . This means that all distributions should now be returned with the default/empty Context instance.

OxidizedFinder.find_distributions() now properly filters when the passed Context ’s name attribute is set to a string. Previously, the name and path attributes had their order swapped in a function call, leading to incorrect filtering.

The Windows standalone_static distributions should now work again. They had been broken for a few releases and likely never worked with Python 3.9. Test coverage of this build configuration has been added to help prevent future regressions. (#360)

Support added for aarch64-apple-darwin (Apple M1 machines). Only Python 3.9 is supported on this architecture. Because we do not have CI coverage for this architecture (due to GitHub Actions not yet having M1 machines), support is considered beta quality at this time.

The FileManifest Starlark type now exposes an add_path() to add a single file to the manifest.

The PythonExecutable Starlark type now exposes a to_file_manifest() to convert the instance to a FileManifest .

The PythonExecutable Starlark type now exposes a to_wix_msi_builder() method to obtain a WiXMSIBuilder , which can be used to generate an MSI installer for the application.

The PythonExecutable Starlark type now exposes a to_wix_bundle_builder() method to obtain a WiXBundleBuilder , which can be used to generate an .exe installer for the application.

The pyembed crate and OxidizedFinder importer now support indexing multiple resources sources. You can have multiple in-memory data blobs, multiple file-based resources, or a mix of all of the above.

The OxidizedFinder Python type now exposed various index_* methods to facilitate loading/indexing of resource data in arbitrary byte buffers or files. You can call these methods multiple times to chain multiple resources blobs together.

The PythonExecutable Starlark type now exposes a packed_resources_load_mode attribute allowing control over where packed resources data is written and how it is loaded at run-time. This attribute facilitates disabling the embedding of packed resources data completely (enabling you to produce an executable that behaves very similarly to python ) and allows writing and loading resources data to a standalone file installed next to the binary (enabling multiple binaries to share the same resources file). See Managing Packed Resources Data for more on this feature.

PyOxidizer now scans for licenses of Python packages processed during building and prints a report about what it finds when writing build artifacts. This feature is best effort and relies on packages properly advertising their license metadata.

Support for configuring Python’s memory allocators has been expanded. The Starlark PythonInterpreterConfig.allocator_debug field has been added and allows enabling Python memory allocator debug hooks. The Starlark PythonInterpreterConfig.allocator_mem , PythonInterpreterConfig.allocator_obj , and PythonInterpreterConfig.allocator_pymalloc_arena fields have been added to control whether to install a custom allocator for the mem and obj domains as well as pymalloc ’s arena allocator.

The mimalloc and snmalloc memory allocators can now be used as Python’s memory allocators. See documentation for PythonInterpreterConfig.allocator_backend . Code contributed by Ryan Clanton in #358.

The mimalloc and snmalloc memory allocators will now automatically be used as Rust’s global allocator when configured to be used by Python.

The @classmethod OxidizedDistribution.find_name() and OxidizedDistribution.discover() are now implemented, filling in a feature gap in importlib.metadata functionality.

There is a new PythonExecutable.windows_runtime_dlls_mode attribute to control how required Windows runtime DLL files should be materialized during application building. By default, if a built binary requires the Visual C++ Redistributable Runtime (e.g. vcruntime140.dll ), PyOxidizer will attempt to locate and copy those files next to the built binary. See Managing the Visual C++ Redistributable Requirement for more.

Documentation around portability of binaries produced with PyOxidizer has been reorganized and overhauled. See Portability of Binaries Built with PyOxidizer for the new documentation.

Python distributions upgraded to CPython 3.8.8 and 3.9.2 (from 3.8.6 and 3.9.0). See https://github.com/indygreg/python-build-standalone/releases/tag/20210103 and https://github.com/indygreg/python-build-standalone/releases/tag/20210227 for a full list of changes in these distributions.

CI has been moved from Azure Pipelines to GitHub Actions.

Low level code in the pyembed crate for loading and indexing resources has been significantly refactored. This code has historically been a bit brittle, as it needs to do unsafe things. We think the new code is much more robust. But there’s a chance that crashes could occur.

When using the no-copyleft (formerly no-gpl ) extension module filter, some system library dependencies are now allowed, enabling various extension modules to be present in this mode.

The pyembed and oxidized-importer crates had their SPDX license expression changed from Python-2.0 AND MPL-2.0 to Python-2.0 OR MPL-2.0 . The author misunderstood what AND did and after realizing his mistake, corrected it to OR so the crates can one license or the other.

When using dynamically linked Python distributions on Windows, the python3.dll file is automatically installed if it is present. (#336)

libclang_rt.osx.a is now linked into Python binaries on macOS. This was necessary to avoid undefined symbols errors from symbols which Python 3.9.1+ relies on.

The oxidized_importer Python module now exports the OxidizedDistribution symbol, which is the custom importlib.metadata distribution type used by OxidizedFinder .

When building with Windows standalone_static distributions, pyoxidizer now sets RUSTFLAGS=-C target-feature=+crt-static -C link-args=/FORCE:MULTIPLE to force static CRT linkage and ignore duplicate symbol errors. Previously, the Python distribution would be using static CRT linkage and the Rust application would use dynamic/DLL CRT linkage. Furthermore, many standalone_static distributions have build configurations that lead to duplicate symbols and this would lead to a linker error. Suppressing the duplicate symbol error is not ideal, but it restores building with standalone_static until a more appropriate workaround can be devised.

The run_as_main() function on embedded Python interpreters now always calls Py_RunMain() . This fixes a regression in previous 0.10 releases that prevented a REPL from running when no explicit run_* attribute was set on the Python interpreter configuration.