NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
pub.dev · #1921 most downloaded on pub.dev
iOS and macOS implementations of the serious_python plugin
Last release 11 days ago
26 Sep 2026
Release timing varies
gaps range from 9 days to 2 months
Nearly every release is documented
notes for 54 of 54 stable releases
1 version withdrawn
withdrawn after publishing
3 years old
55 releases · first in 2023
Stop splitting exclude and cleanup globs on commas; prepare 5.0.0 by @FeodorFitsner in #253
Full Changelog: v4.7.2...v5.0.0
fix(darwin): re-sign linker-signed macOS native modules while staging by @ndonkoHenri in #251
One column per month.
Full Changelog: v4.7.1...v4.7.2
90238 ("does not satisfy its designated Requirement") caused by linker-signed native modules (#250, #251). Staging now replaces linker signatures on .so and .dylib files in the stdlib, site-packages and app with regular ad-hoc signatures. This preserves their signing identifiers when Xcode re-signs them for distribution, avoiding a mismatch with their designated requirements.pod install now stops when a Python runtime preparation script exits with an error. Previously, the podspec ignored these failures, allowing builds to continue despite native module signing errors, provider integrity mismatches, or provider signature verification failures in require mode. (#251)DartBridge.hardExit, and re-pin python-build to 20260908 by @FeodorFitsner in #248
Full Changelog: v4.7.0...v4.7.1
dart_bridge 1.10.0. (dart-bridge#21, #85)dart_bridge to 1.10.0. CPython versions remain 3.12.14 / 3.13.15 / 3.14.7. (python-build#42)Full Changelog : v4.6.0...v4.7.0
Full Changelog: v4.6.0...v4.7.0
dart_bridge to 1.9.0, whose dart_bridge.xcframework adds the serious_python_hard_exit export behind DartBridge.hardExit. No CPython or Pyodide versions change from 4.6.0 - 3.12.14 / 3.13.15 / 3.14.7 are unchanged, and the python-build release exists to publish the updated manifest.fix: pass --no-input and bounded timeouts to pip by @ndonkoHenri in #246
--no-input and bounded timeouts to pip by @ndonkoHenri in #246Full Changelog: v4.5.1...v4.6.0
html.parser.HTMLParser parsing (gh-153030) and quadratic behaviour in xml.etree.ElementTree XPath index predicates (gh-152674), among others. 3.13.15 and 3.14.7 still bundle libexpat 2.8.2; only 3.12.14 carries 2.8.3 with the CVE-2026-72522 fix — see the serious_python 4.6.0 notes.python-ios-dart-3.14.7: 56 XCFrameworks and 112 slice frameworks, all signed and securely timestamped by Apple Distribution: Appveyor Systems Inc. (GXXRQJK434), zero unsigned bundles and zero missing timestamps — the same counts as 3.14.6 in 4.5.1. The isSecureTimestamp = false reading discussed in 4.5.1 is unchanged and still believed unreachable by signing.dup3/pipe2 change from 3.14 (gh-153711), which split the configure check that python-build's vendored Apple-tooling patch widens; the patch was updated so both halves of the split keep the non-iOS Apple platforms gated off. See flet-dev/python-build#40.dart_bridge 1.7.1 → 1.8.0). Pyodide 3.14 314.0.3 → 314.0.6.Bump to 4.5.1: sign and verify both XCFramework layers by @FeodorFitsner in #245
Full Changelog: v4.5.0...v4.5.1
.framework as well as the outer .xcframework. 4.5.0 shipped artifacts whose outer bundle was signed but whose inner frameworks were not. An App Store IPA built against it reported signed = true — the 4.5.0 fix working — but isSecureTimestamp = false for Python-ios, _ssl, _hashlib and dart_bridge, in both a development archive and an App Store export. Every slice of an XCFramework Apple's scan demonstrably accepts (krzyzanowskim/OpenSSL 3.6.3000) carries its own Apple Distribution signature with a secure timestamp, with the outer bundle signed last; an unsigned inner framework was the only structural difference left. See flet-dev/python-build#38 and flet-dev/dart-bridge#14.isSecureTimestamp, and that appears not to be something signing can change. With both layers signed, the receipts still read signed = true / isSecureTimestamp = false. The receipt's cdhashes entry matches the outer xcframework's CDHash exactly — so Xcode reads the outer signature, which carries a genuine Apple TSA Timestamp=, and reports isSecureTimestamp = false anyway. Every receipt in the archive reports false, and the receipts record signatureType = AppleDeveloperProgram; the accepted OpenSSL artifact is signed by an Apple Distribution identity too, so it would carry the same type. Decoding the CMS blob in _CodeSignature/CodeSignature settles it: our signature carries a genuine RFC 3161 id-smime-aa-timeStampToken (1.2.840.113549.1.9.16.2.14) unsigned attribute — a real TSA token, not just a self-asserted signingTime — and its attribute set is structurally identical to the accepted OpenSSL artifact's, down to the Apple certificate extensions. There is no observable difference left between the two signatures, so isSecureTimestamp = false cannot be caused by anything in ours. The reasonable reading is that ITMS-91065: Missing signature tests signed, which is now true, and that isSecureTimestamp is not reachable for a Developer Program identity. Signing both layers is kept regardless: it matches what an accepted artifact does, and it is correct practice for a distributed binary framework.spv_verify_provider checks each slice's inner framework as well as the outer bundle, so an unsigned slice fails during packaging rather than surfacing in an IPA weeks later. Slice frameworks are located by glob rather than by the xcframework's name, since stage_spm.sh stages Python.xcframework as Python-<platform>.xcframework and a name-keyed lookup would silently find nothing there. Signature presence is probed with codesign -dv rather than by looking for _CodeSignature, because a versioned macOS bundle keeps it under Versions/<name>/ and that name is not always A — CPython uses Versions/3.14.dart_bridge 1.7.0 → 1.7.1). No Python version moved — 3.12.13 / 3.13.14 / 3.14.6 and Pyodide are unchanged from 20260729. Verified on the published artifacts: 56 XCFrameworks and 112 slice frameworks in python-ios-dart-3.14.6, all signed and securely timestamped by Apple Distribution: Appveyor Systems Inc. (GXXRQJK434).Python.framework layout: Headers and Modules were real directories at the framework root, which codesign rejects for a versioned bundle (unsealed contents present in the root directory of an embedded framework). They are now symlinks into Versions/Current, as CPython's own framework does for Headers and Resources. See flet-dev/python-build#39.Bump to 4.5.0: preserve provider XCFramework signatures through staging by @FeodorFitsner in #244
Full Changelog: v4.4.2...v4.5.0
Python.xcframework, dart_bridge.xcframework, and every stdlib extension framework arrive pre-built from flet-dev/python-build and flet-dev/dart-bridge. serious_python no longer rewrites anything inside them: the SERIOUS_PYTHON_BUNDLE_ID pass now applies only to frameworks built here from the app's own wheels, which are generated in a separate directory, mutated there, and merged with the untouched provider artifacts afterwards. reconcile_framework_install_names (which rewrites Mach-O headers and re-signs ad-hoc) likewise never reaches a provider binary.codesign -f at embed and exportArchive overwrites it. The overwrite is real but the conclusion was wrong: Xcode separately records the state of each .xcframework as its publisher shipped it, and writes that into the IPA as Signatures/<name>.xcframework-ios.signature with signed and isSecureTimestamp flags. ITMS-91065: Missing signature reports on those receipts, not on the embedded copy. Namespacing CFBundleIdentifier under the host app was therefore not a fix, and was actively counterproductive — the plist edit invalidated the very signature the receipt reports on. The 4.4.2 identifier rewrite is reverted for provider frameworks and kept for locally built ones, where it is harmless and matches CPython's convention.SERIOUS_PYTHON_VERIFY_PROVIDER_SIGNATURES (warn default / require / off) additionally checks that each provider XCFramework carries a real, securely timestamped publisher signature; SERIOUS_PYTHON_EXPECTED_TEAM_ID pins the expected Apple Team ID. The default is warn so that pinning an older, pre-signing python-build or dart-bridge release still builds — use require for App Store submissions..framework bundles in a Pods-Runner-frameworks.sh script phase; Xcode writes SDK-origin receipts only for xcframeworks it consumes as declared binary dependencies, so that path cannot produce complete receipts no matter how the source is signed. It now emits an Xcode warning: saying so. The SwiftPM path declares them as binaryTargets and is unaffected.dev.flet.python.runtime for the Python runtime, dev.flet.python.<module> for each stdlib extension, dev.flet.dartbridge for the bridge. They no longer depend on the consuming app, which is what allows one publisher signature to cover every app.dart_bridge 1.6.1 → 1.7.0). No Python version moved — 3.12.13 / 3.13.14 / 3.14.6 and Pyodide are unchanged from 20260727. What did change is that every Apple XCFramework in that release, and dart_bridge.xcframework in 1.7.0, is now signed by the Flet publishing team's Apple Distribution identity with a secure timestamp: verified on the published artifacts as Authority=Apple Distribution: Appveyor Systems Inc. (GXXRQJK434), a real Timestamp=, and an outer _CodeSignature/CodeResources — 56 XCFrameworks in python-ios-dart-3.14.6, plus the macOS and mobile-forge runtimes. See flet-dev/python-build#37 and flet-dev/dart-bridge#13.Bump to 4.4.2: Xcode build-provenance keys in iOS framework Info.plists by @FeodorFitsner in #242
Full Changelog: v4.4.1...v4.4.2
org.python.<module> CFBundleIdentifier — org.python.ssl, org.python.hashlib, … — byte-identical in every app ever built with serious_python. Set SERIOUS_PYTHON_BUNDLE_ID to the app's bundle identifier and they become com.example.myapp.-ssl instead, matching what CPython's own iOS support does when it converts a .so into a framework. This matters because a framework's bundle identifier also becomes its code signing identifier, which is the one field that survives the codesign -f Xcode applies at embed and again at exportArchive. Python.framework is covered too — it was org.python.python in every app; nothing resolves it by identifier (the string appears in no shipped binary and there are no CFBundleGetBundleWithIdentifier lookups), so the rename is inert at runtime. dart_bridge.framework is deliberately left at dev.flet.dartbridge, which is already a vendor-owned identifier rather than a shared placeholder. Unset, or set to something that isn't a valid bundle identifier, leaves the old defaults in place and prints a warning. flet build supplies it from your app's configured bundle id (flet-dev/flet#6731).Info.plist. Every framework built from a lib-dynload .so — _ssl, _hashlib, and the rest — previously shipped ten hand-written keys and not a single DT* key, so to Apple's static analysis the bundle didn't look like anything Xcode had produced. They now carry the same key set Xcode stamps into a real framework (BuildMachineOSBuild, DTCompiler, DTPlatformBuild, DTPlatformName, DTPlatformVersion, DTSDKBuild, DTSDKName, DTXcode, DTXcodeBuild, UIDeviceFamily, and UIRequiredDeviceCapabilities on the device slice), resolved from the SDK the release was built with. The simulator slice is also labelled correctly now — it previously claimed CFBundleSupportedPlatforms=iPhoneOS. See flet-dev/python-build#36.ITMS-91065: Missing signature App Store rejection in flet-dev/flet#6724, neither is a confirmed fix. The shared bundle identifier is the stronger of the two: it accounts for every outcome we could find (BeeWare namespaces under the app and has no reports; a third-party OpenSSL xcframework with its own vendor identifier is reported to pass; our org.python.* and one other project's independent identifier both draw the rejection). Two further candidates were ruled out experimentally: a signature applied at the source can't matter (re-signing the way exportArchive does destroys the certificate chain, team identifier and timestamp, leaving only the identifier string, which is derived from CFBundleIdentifier for an unsigned framework anyway), and the privacy manifest can't be the differentiator (a third-party OpenSSL xcframework the App Store accepts ships an empty stub, and our frameworks already carry a manifest — Apple emits no ITMS-91061 alongside the rejection). The check only fires for new apps, or updates that newly add a listed SDK, so existing published apps are unaffected either way.dart_bridge 1.6.1 are unchanged from 20260726, and the Info.plist change above is the only functional difference on any platform.Bump to 4.4.1: OpenSSL privacy manifest for iOS _ssl/_hashlib by @FeodorFitsner in #241
Full Changelog: v4.4.0...v4.4.1
_ssl.framework and _hashlib.framework now carry OpenSSL's official privacy manifest. Both extensions statically link OpenSSL, so Apple's App Store scan identifies them as containing BoringSSL / openssl_grpc — a listed third-party SDK that must declare a privacy manifest. The bundled PrivacyInfo.xcprivacy was a stub: NSPrivacyAccessedAPITypes was an empty array, and it carried an NSPrivacyUsesNonStandardAPIs key that isn't part of Apple's schema. It is now byte-identical to the manifest OpenSSL publishes for its Apple builds, declaring the file-timestamp API access the library actually performs (NSPrivacyAccessedAPICategoryFileTimestamp, reason C617.1). See flet-dev/python-build#35.ITMS-91065: Missing signature App Store rejection reported in flet-dev/flet#6724, and shouldn't be read as a fix for it. That rejection cites the same two frameworks but arrives with no accompanying ITMS-91061, so Apple does find the manifest. Inspecting a built .ipa confirms the frameworks reach Apple signed — valid Apple Distribution authority and team ID, with the manifest sealed into _CodeSignature/CodeResources — and that Xcode re-signs every embedded framework with the submitting team's identity at both the embed and exportArchive steps, overwriting whatever signature the vendor applied. Root cause is still open; this change removes the one verifiable defect so it isn't a confound.dart_bridge 1.6.1 are all unchanged from 20260725, and the privacy manifest above is the only functional difference on any platform.Bump to 4.4.0: dart_bridge as a dynamic framework on Apple platforms by @FeodorFitsner in #240
Full Changelog: v4.3.6...v4.4.0
dart_bridge now ships as a dynamic framework, fixing built iOS apps crashing at startup with Failed to lookup symbol 'serious_python_run': dlsym(RTLD_DEFAULT, serious_python_run): symbol not found. dart_bridge's FFI entry points (serious_python_run, DartBridge_InitDartApiDL, DartBridge_EnqueueMessage, PyInit_dart_bridge) are resolved at runtime via dlsym — from Dart through DynamicLibrary.process() and from Python through import dart_bridge. It previously shipped as a static archive linked into the host app executable, and an iOS executable exports nothing to the dynamic symbol table by default (the release build also strips local symbols), so those lookups failed. Only release/archive (device) builds were affected — debug/simulator builds don't dead-strip, so the failure did not reproduce there. Android was never affected: its dart_bridge is a dynamic .so, which exports its symbols. dart_bridge 1.6.1 now builds dart_bridge.xcframework as a dynamic framework (see flet-dev/dart-bridge#11 and #12), so it is embedded + signed into the app like Python.xcframework and its symbols stay exported. The SwiftPM -all_load / -force_load retention, the CocoaPods -all_load, and the plugin's dead-strip keep-alive references are all removed — a loaded image needs none of them.dart_bridge 1.5.1 → 1.6.1). Python versions (3.12.13 / 3.13.14 / 3.14.6) are unchanged and the iOS/macOS CPython runtimes are byte-identical to 20260720.Bump to 4.3.6: Windows UTF-8 startup fix (dart_bridge 1.5.1, python-build 20260720) by @FeodorFitsner in #238
concurrent.interpreters / InterpreterPoolExecutor) by @ndonkoHenri in #239Full Changelog: v4.3.4...v4.3.6
dart_bridge 1.5.0 → 1.5.1). 1.5.1 is a Windows-only UTF-8 startup fix (see serious_python_windows 4.3.6); the iOS/macOS runtimes are functionally unchanged from 20260719.Nothing published for this version
Bump to 4.3.4: Android flet debug stale-code fix (flet #6682) by @FeodorFitsner in #235
flet debug stale-code fix (flet #6682) by @FeodorFitsner in #235Full Changelog: v4.3.3...v4.3.4
_pyrepl on Windows/Linux desktop (fixing a 3.14 pydoc/pdb crash — see serious_python_windows / serious_python_linux 4.3.4); iOS/macOS already shipped _pyrepl (un-pruned in 4.3.2), so these runtimes are byte-identical to 20260714. No iOS/macOS-affecting changes.Fix Windows build failure on non-UTF-8 locales (C4819/C2220) by @FeodorFitsner in #234
Full Changelog: v4.3.2...v4.3.3
serious_python_* 4.3.3 release (a Windows build fix). No iOS/macOS-affecting changes.Bump to 4.3.2: python-build 20260712 (Android mimalloc seccomp crash, mobile _pyrepl restored) by @FeodorFitsner in #230
Full Changelog: v4.3.1...v4.3.2
.so/.dylibs are wrapped into frameworks named by their dotted relative path (opt/lib/libarrow.dylib → opt.lib.libarrow.framework/opt.lib.libarrow), but the Mach-O install-id and every interdependent @rpath reference were left at their original bare name (@rpath/libarrow.dylib). Because each framework is a Package.swift binaryTarget linked at launch, dyld could not resolve @rpath/libarrow.dylib (it looks for Frameworks/libarrow.dylib, which does not exist) and the app crashed before Python started — hitting any package that bundles a chain of interdependent libs (pyarrow's libarrow/libarrow_compute/libarrow_python, llama-cpp-python's libggml*/libllama). A new reconcile pass, run after sync_site_packages frameworks the libs, sets each framework's own install-id to @rpath/<fw>.framework/<fw> and rewrites every dependency pointing at a sibling's old id to that framework path, then re-signs. The Python/stdlib xcframeworks are left untouched. (This supersedes the 4.2.1 approach of preserving .dylib install-names, which only worked when every sibling happened to be loaded first.)install_name_tool/codesign error, notably insufficient Mach-O header space to grow a load command (which would otherwise leave a bare @rpath ref and reproduce the launch crash), and records every framework slice's old install-id so a lib with divergent per-slice install names has all slices rewritten.20260714 (Python/dart_bridge versions are unchanged), with two iOS fixes:
_pyrepl is no longer pruned from the bundled stdlib: Python 3.14's pdb imports _pyrepl at module load, so anything importing pdb (e.g. pytest's debugging plugin) died with ModuleNotFoundError: No module named '_pyrepl' on iOS (3.13's pdb doesn't import it)._posixshmem extension is now built into the iOS runtimes: multiprocessing.resource_tracker — imported transitively by import multiprocessing (e.g. scikit-learn → joblib) — unconditionally imports it on posix, so with _multiprocessing enabled (since 20260701) but _posixshmem missing, any multiprocessing user died with ModuleNotFoundError: No module named '_posixshmem'. Process spawning remains unsupported in the iOS sandbox — this only makes the shared-memory module importable.Version bump aligning with the serious_python_* 4.3.1 release.
serious_python_* 4.3.1 release.Bump dart_bridge to 1.5.0 (python-build snapshot 20260708): multiprocessing child-interception exports (serious_python_is_mp_invocation / serious_pyth
dart_bridge to 1.5.0 (python-build snapshot 20260708): multiprocessing child-interception exports (serious_python_is_mp_invocation / serious_python_main), kept alive against the host link's -dead_strip both by __attribute__((used)) in the archive and by keep-alive references in SeriousPythonPlugin.swift. See the serious_python 4.3.0 notes.prepare_macos.sh / prepare_ios.sh: the extracted dart_bridge.xcframework in dist_* is now keyed to the dart_bridge version (.dart_bridge_version marker) — previously a version bump kept staging the stale extraction from the earlier version.PYTHONINSPECT=1 is no longer set by any platform implementation. It had no effect on the embedded interpreter, but it leaked into the process environment where any real interpreter child (e.g. a serviced multiprocessing worker) would inherit it and hang in interactive mode after its command completed.Framework-ize ctypes .dylib shared libs (not just .so C-extensions) when syncing iOS site-packages, so .dylib-shipping packages (e.g. llama-cpp-python
.dylib shared libs (not just .so C-extensions) when syncing iOS site-packages, so .dylib-shipping packages (e.g. llama-cpp-python) load on the iOS simulator instead of failing dlopen with incompatible platform (have 'iOS', need 'iOS-simulator'). Each .dylib becomes a device+simulator xcframework + .fwork pointer, exactly like .so; unlike .so (whose id is rewritten to the framework path), the .dylib install-name is preserved so multi-lib packages resolve their sibling libs. The .so path is unchanged.20260701: the iOS runtime now builds the _multiprocessing extension (importable, not spawnable). Python/dart_bridge versions are unchanged from 20260630.Bump the bundled python-build snapshot to 20260630 (dart_bridge 1.4.1); aligns with the serious_python_* 4.2.0 release.
20260630 (dart_bridge 1.4.1); aligns with the serious_python_* 4.2.0 release.Version bump aligning with the serious_python_* 4.1.1 release.
serious_python_* 4.1.1 release.Version bump aligning with the serious_python_* 4.1.0 release.
serious_python_* 4.1.0 release.Swift Package Manager support (dual with CocoaPods). The plugin now builds under SPM as well as CocoaPods, so apps can use either integration (CocoaPo
darwin/serious_python_darwin/Package.swift builds the same Swift source as the podspec, with getResourcePath resolving Bundle.module under SPM (#if SWIFT_PACKAGE) and the framework python.bundle under CocoaPods.
prepare_command does runs on the host before flutter build instead: prepare_spm.sh assembles the dist (prepare_<platform>.sh + sync_site_packages.sh) and stage_spm.sh maps it into the package layout — Python-{ios,macos}.xcframework + dart_bridge.xcframework as local-path binary targets, the iOS native C-extensions enumerated from extra-xcframeworks/, and stdlib/site-packages/app as .copy resources. On iOS the extensions ship as embedded, signed frameworks (CPython's .fwork finder resolves them); on macOS they load flat from the resource trees.SP_NATIVE_SET (a hash of the staged native set) so SwiftPM re-resolves when requirements / app / Python version change — SwiftPM caches its package graph on manifest text + environment, not on the staged dirs it enumerates.Package.swift is dormant on older Flutter (which uses the CocoaPods path).prepareApp() returns the app dir from the python.bundle resource (<resourcePath>/app); the app's Python sources ship unpacked as an app resource bundle next to stdlib + site-packages (no first-launch extraction).serious_python_* 4.0.0 release.Breaking change: requires Flutter 3.44.2.
dart_bridge.xcframework (from flet-dev/dart-bridge 1.4.0) instead of a socket transport; the Swift plugin registers the dart_bridge inittab, the pod is declared static_framework for xcframework vendoring, and the embedded Python.app is stripped from Python.framework.python_versions.properties (a snapshot of python-build's manifest.json) and passes the full version, build date and dart_bridge version to prepare_ios.sh / prepare_macos.sh (dart_bridge_version is $4); SERIOUS_PYTHON_VERSION is the knob, the per-field env vars are escape hatches. The prepare scripts re-extract dist_ios / dist_macos when the selected version changes (a version marker) so a clean build can't mix C-extension ABIs.getPlatformVersion method.Breaking change: default bundled Python version is now 3.14 (was 3.12). Apps built without an explicit SERIOUS_PYTHON_VERSION env var pull python-ios-…
SERIOUS_PYTHON_VERSION env var pull python-ios-dart-3.14.tar.gz / python-macos-dart-3.14.tar.gz from flet-dev/python-build. Set SERIOUS_PYTHON_VERSION=3.12 to preserve the previous default.python_version in serious_python_darwin.podspec reads from SERIOUS_PYTHON_VERSION; prepare_ios.sh / prepare_macos.sh already took the version as $1 and download the matching tarballs.Cache downloaded Python distribution tarballs (python-android-dart- - .tar.gz) across builds. The downloadDistArchive_* Gradle tasks now write to a pe
python-android-dart-<py>-<abi>.tar.gz) across builds. The downloadDistArchive_* Gradle tasks now write to a persistent cache directory — $FLET_CACHE_DIR/python-build/v<python_version>/ if the env var is set, otherwise ~/.flet/cache/python-build/v<python_version>/ — and use onlyIfModified true + useETag "all" so subsequent builds issue a conditional GET (If-None-Match / If-Modified-Since) against objects.githubusercontent.com instead of re-downloading 30–100 MB per ABI per build. When the upstream release republishes a tarball at the same URL (e.g. a Python patch update under the existing v<py> release), the validators flip and the cache refreshes automatically; otherwise the build skips the download entirely. tempAndMove true guards against partial downloads being kept in the cache (flet-dev/flet#6555, #208) by @FeodorFitsner.Breaking change: --platform argument value Pyodide has been renamed to Emscripten to match what platform.system() returns in the Pyodide runtime, so P…
--platform argument value Pyodide has been renamed to Emscripten to match what platform.system() returns in the Pyodide runtime, so PEP 508 markers like platform_system != 'Emscripten' work consistently.Fix web packaging to skip site-packages when appropriate (#199).
site-packages when appropriate (#199).Disable user-site packages in pip environment (#195).
Android: Add debug logs and deduplicate FFI imports.
Add zipDirectoryPosix to create POSIX-compliant app archives on Windows.
serious_python plugin build.WINDIR path for bundled DLLs in CMake.* Fix logging on Android.
Redirect Python output to logcat.
Make zipDirectory call asynchronous.
Fixed iOS framework identifier generation.
archive to ^4.0.7.16 KB memory page support for Android 15+ (by @ReYaNOW).
Fix: Hidden files in site-packages are skipped when building macOS app.
.dist-info directories (#164).Breaking change: multiple --requirements options of package command must be passed as --requirements DEP_1 --requirements DEP_2 ... (or -r DEP_1 -r DE…
--requirements options of package command must be passed as --requirements DEP_1 --requirements DEP_2 ... (or -r DEP_1 -r DEP_2 ...) instead of -r DEP_1,DEP_2,... to support dependency specifications with commas, e.g. pandas>=2.2,<3.Fix serious_python to work on macOS 12 Monterey and built with Xcode 14.
serious_python to work on macOS 12 Monterey and built with Xcode 14.Set MinimumOSVersion to 13.0 for generated Python frameworks.
MinimumOSVersion to 13.0 for generated Python frameworks.python.bundle to pass App Store verification.--cleanup option replaced with two separate --cleanup-app and --cleanup-packages options.--cleanup-app-files and --cleanup-package-files to specify a list of globs to exclude files and directories from app and site packages.--skip-site-packages option to skip site packages installation for faster re-builds.--arch option accepts a list now.Fixed: xcframeworks migration script didn't work for sub-directories.
xcframeworks migration script didn't work for sub-directories.Added com.flet.serious_python_android.PythonActivity holder class with mActivity holding a reference to an app MainActivity. Needed for plyer.
com.flet.serious_python_android.PythonActivity holder class with mActivity holding a reference to an app MainActivity. Needed for plyer.MAIN_ACTIVITY_HOST_CLASS_NAME environment variable with the name of activity holder class name (com.flet.serious_python_android.PythonActivity).MAIN_ACTIVITY_CLASS_NAME environment variable with a class name of an app MainActivity.ANDROID_NATIVE_LIBRARY_DIR environment variable with the path to a directory containing app .so libraries. Needed for patching ctypes.find_library.SERIOUS_PYTHON_ALLOW_SOURCE_DISTRIBUTIONS environment variable that should contain a comma-separated list of packages to allow installation from source distribution.site-packages to xcframeworks migration script supports both library.so and library.{something}.so.Added Java loadLibrary to Android plugin to support pyjnius (#128).
loadLibrary to Android plugin to support pyjnius (#128).Copy site-packages/flutter contents to SERIOUS_PYTHON_FLUTTER_PACKAGES.
site-packages/flutter contents to SERIOUS_PYTHON_FLUTTER_PACKAGES.SERIOUS_PYTHON_ALLOW_SOURCE_DISTRIBUTIONS variable to allow pip installing from source distributions.Remove PYTHONOPTIMIZE=2 to make CFFI work.
PYTHONOPTIMIZE=2 to make CFFI work.Copy .so libraries from {site-packages}/opt to jniLibs.
.so libraries from {site-packages}/opt to jniLibs.Remove --only-binary when packaging for desktop platforms
New packaging, not based on Kivy and with pre-built binary packages.
Added namespace definition to Android Gradle build.
namespace definition to Android Gradle build.runPython() method to support running Python script.
runPython() method to support running Python script.flet_example to catch program output and errors, sys.exit() support.package command to read dependencies from pyproject.toml.--exclude option for package command - to exclude directories and files from Python app package.
--exclude option for package command - to exclude directories and files from Python app package.package command.--verbose flag - verbose output.
--verbose flag - verbose output.--mobile flag - (removes .so) from app dest archive.--web flag for packaging for pyodide.--find-links option for installing pip dependencies from alternative sources (indexes).--dep-mappings for rewriting flet dependency to either flet-embed or flet-pyodide.--req-deps for adding required dependencies like flet-embed or flet-pyodide.--platform option for use with sitecustomize.py to tweak pip to pull platform-specific packages.Simplified Python initialization on Android.
* Python 3.11.6.
Bumping version after fixing pubspec.yaml.
* macOS support.
Your coding agent can read these notes before it upgrades. Set up the MCP server →