Releases: indygreg/PyOxidizer
PyOxidizer 0.24.0
The documentation for this release is at https://gregoryszorc.com/docs/pyoxidizer/0.24.0/.
Backwards Compatibility Notes
- The minimum Rust version has been changed from 1.61 to 1.65.0.
Bug Fixes
- Fixed a bad regression in 0.23.0 that was causing Python symbols to not get
exported from built binaries, which was causing extension modules to not load
successfully. (Extension module imports would fail withundefined symbol
errors, or similar.) (#663).
Changes
- Default CPython distributions upgraded. CPython 3.8.15 -> 3.8.16; 3.9.15 ->
3.9.16; 3.10.8 -> 3.10.9.
See https://github.com/indygreg/python-build-standalone/releases/tag/20221220
for additional changes.
Other Relevant Changes
- Managed Rust toolchain upgraded from 1.61.0 to 1.66.0.
- Package versions in autogenerated
Cargo.toml
are now defined to the patch
level. - SPDX license list upgraded from 1.18 to 1.19.
PyOxidizer 0.23.0
The documentation for this release is at https://gregoryszorc.com/docs/pyoxidizer/0.23.0/.
Backwards Compatibility Notes
- The minimum Rust version has been changed from 1.60 to 1.61 to facilitate
use of features required by some Rust crates.
Bug Fixes
- 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 a3.1
directory instead of3.10
. (#569, #600). - Changed interpreter initialization logic around
sys.meta_path
handling to
be more resistant to additional entries. Ifsite
is imported during
interpreter initialization, a.pth
file insite-packages
could have
the side-effect of registering additional entries onsys.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)
Changes
- 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 emittingcargo:rustc-link-arg=FLAG
lines from Cargo build
scripts. There should be no change in behavior. Generated Rust projects with a
.cargo/config
overridingrustflags
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 toPython.h
.
Apple Codesign 0.17.0
The apple-codesign project has moved to https://github.com/indygreg/apple-platform-rs. This is the final release to be published from the PyOxidizer repository. All future releases can be found at https://github.com/indygreg/apple-platform-rs/releases.
Release Info
Changelog
- Major feature: Notarization is now implemented in Rust and no longer
requires Apple's Transporter application. Going forward, you only need
thercodesign
executable (or this crate embedded as a library) and an
App Store Connect API Key to notarize. Major thanks to Robin Lambertz
(@roblabla) for contributing the bulk of the implementation in #593. - As a result of native notarization, integration with Apple's Transporter
has been removed. Thefind-transporter
command has been removed. Rust
APIs related to Transporter, the app metadata XML format it used, and App
Store Connect APIs previously used have been removed. - As a result of native notarization, UI and implementation details of
notarization have changed. The output when uploading assets is much more
concise. Before, code existed to normalize uploaded assets to a data format
required by Transporter. As a side-effect, assets were somewhat validated
locally before upload. In the new world, minimal checks are performed locally.
This can result in errors (such as attempting to upload an asset without a
code signature) occurring later than they did previously. - A new
encode-app-store-connect-api-key
command can be used to encode an
App Store Connect API Key in a single JSON object. These keys are used for
notarization and having all the API Key metadata in a single file / JSON
blob means you have 1 entity to define your App Store Connect API Key instead
of 3, making UI simpler. - The
notarize
command has been renamed tonotary-submit
. This follows
the terminology of Apple'snotarytool
and mimics the nomenclature used
by the Notary API. The oldnotarize
command is an alias to
notary-submit
. - The
notary-submit
command now has an--api-key-path
argument defining the
path to a JSON file containing the unified App Store Connect API Key emitted
by theencode-app-store-connect-api-key
command. We recommend using this
method for specifying the API Key going forward, as it is simpler. The old
method was required for use with Apple's Transporter application, which we
no longer use so we're no longer bound by its requirements. The old method
will likely be dropped from a future release. - A new
notary-wait
command can be used to wait on a previous notary
submission to complete and to view its log info. This command can be useful if
notary-submit
times out or otherwise fails and you want to query the
status of a previous notarization. - A new
notary-log
command will fetch the notarization log of a previous
submission from the Notary API server. - Fixed signing of Mach-O binaries having a gap between segments. (This is known
to commonly occur in Go binaries.) In previous versions, we would compute
digests of the file incorrectly and would encounter an assertion when copying
Mach-O data to the output binary. Both of these issues should now be fixed.
(#588 and #616) - minicbor crate upgraded from version 0.15. This created API differences in
remote signing code. - The APIs around Mach-O file parsing have been significantly overhauled. It
is probably best to diff themacho
module to see the full differences.
There are nowMachFile
andMachOBinary
types serving as interfaces
to custom Mach-O functionality. Most code interfacing with a Mach-O file now
uses these types. TheAppleSignable
trait has been deleted as it is no
longer needed since we have the dedicatedMachOBinary
type.
PyOxidizer 0.22.0
- Distributed macOS binaries no longer dynamically link
liblzma.5.dylib
.
PyOxidizer 0.21.0
The documentation for this release is at https://pyoxidizer.readthedocs.io/en/pyoxidizer-0.21.0/pyoxidizer.html.
Backwards Compatibility Notes
- 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).
Bug Fixes
- 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 theclap
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 variouspython
invocations. Previously, invocations ofpip
,
setup.py
, and other processes could result in a panic if invalid UTF-8 was
emitted. (#579)
New Features
-
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 aCargo.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 Python 3.9+ for Apple M1 is
strongly advised.
Other Relevant Changes
- Managed Rust toolchain upgraded from 1.56.1 to 1.61.0.
- Starlark
PythonInterpreterConfig
documentation has been changed
to refer topyembed_interpreter_config
. 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. - See https://github.com/indygreg/PyOxidizer/releases/tag/oxidized_importer%2Fpython-oxidized-importer%2F0.6.0 for relevant changes in the
oxidized_importer
extension module.
Oxidized Importer Python Extension python-oxidized-importer/0.6.0
- Added missing API docs for
OxidizedDistribution
. OxidizedDistribution.metadata
now returns an
importlib.metadata._adapters.Message
instance on Python 3.10+.OxidizedDistribution.entry_points
now calls
importlib.metadata.EntryPoints._from_text_for
on Python 3.10+.
Previously, the implementation of this method didn't work properly on 3.10+.- Added
name
property toOxidizedDistribution
. - Added
_normalized_name
property toOxidizedDistribution
. - PyO3 Rust crate upgraded to 0.16.5. This gets us better compatibility with
Python 3.10.
Apple Codesign 0.16.0
- Distributed macOS binaries no longer dynamically link
liblzma.5.dylib
.
Apple Codesign 0.15.0
- XAR files are now always signed through a temporary file in order to avoid corruption of the XAR file.
PyOxy 0.2.0
The documentation for this release is at https://pyoxidizer.readthedocs.io/en/pyoxy-0.2.0/pyoxy.html.
- Official release artifacts now contain Python 3.8 and 3.10 variants.
Previously, only Python 3.9 was provided. - The Sphinx documentation now contains extensive documentation for the
Python interpreter configuration structs and enums. The content is derived
from the canonical Rust source code. This should make it easier to
understand the fields in YAML configurations without having to consult
Rust crate docs. - Release artifacts are now
.tar.gz
files and contain aCOPYING
file with licensing annotations. - The release mechanism for PyOxy is now streamlined, hopefully enabling
faster releases going forward.
PyOxy 0.1
Initial release.
See blog post at https://gregoryszorc.com/blog/2022/05/10/announcing-the-pyoxy-python-runner/ and docs at https://pyoxidizer.readthedocs.io/en/latest/pyoxy.html
Software licenses are not part of the release artifacts at this time. The pyoxy
binaries contain software subject to the various LICENSE.*
files in the https://github.com/indygreg/python-build-standalone repository. This may include GPL licensed software. A future release will contain license files and will remove GPL licensed software (if there is any).