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 with undefined 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 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)

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 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.

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

• Documentation
• Known issues and limitations
• Debugging and bug filing instructions

Changelog

• Major feature: Notarization is now implemented in Rust and no longer
  requires Apple's Transporter application. Going forward, you only need
  the rcodesign 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. The find-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 to notary-submit. This follows
  the terminology of Apple's notarytool and mimics the nomenclature used
  by the Notary API. The old notarize 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 the encode-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 the macho module to see the full differences.
  There are now MachFile and MachOBinary types serving as interfaces
  to custom Mach-O functionality. Most code interfacing with a Mach-O file now
  uses these types. The AppleSignable trait has been deleted as it is no
  longer needed since we have the dedicated MachOBinary 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 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)

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 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 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 to pyembed_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 to OxidizedDistribution.
• Added _normalized_name property to OxidizedDistribution.
• 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 a COPYING
  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).