Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Parallel builds on one machine can bundle each other's Python app (staging lives in the plugin's folder in the shared pub cache)

Offen
  • Stimmt etwas nicht?
#255 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
android, dart, flutter, ios, kotlin, macos, python, swift
Bereich
build-system, desktop, mobile

Rechercherichtung

Start with src/serious_python/bin/package_command.dart, src/serious_python_darwin/darwin/sync_site_packages.sh and stage_spm.sh, then inspect src/serious_python_android/android/build.gradle.kts and the reproduction steps. Compare how iOS, macOS and Android stage generated app data in the shared pub cache. Done means concurrent builds cannot package another project's app or partially written artifacts; the issue offers several possible fixes but does not specify a single design.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

What happens

Two builds of serious_python apps that run at the same time on one machine can ship each other's Python app. Nothing fails or warns: the app installs, starts and runs the other project's code.

We hit it three times in one evening (serious_python 5.0.0 through flet build ios-simulator from Flet 1.1, Flutter 3.47.7, Xcode 27, iOS 26.5 simulator), building one Flet app from several git worktrees in parallel:

  • a build's own build/python-app/ (its SERIOUS_PYTHON_APP) held a new module, ui/badges.pyc, but the installed Runner.app/serious_python_darwin_serious_python_darwin.bundle/app/ did not;
  • ~/.pub-cache/hosted/pub.dev/serious_python_darwin-5.0.0/darwin/dist_ios/app/ had been rewritten a minute after that build packaged its app, by a parallel build in another worktree, and the installed bundle matched that copy;
  • in another case the app crashed at start on the other worktree's config file; the traceback paths named the other worktree's build/site-packages.

Why

serious_python stages each app inside the plugin's own package directory, and Flutter resolves plugins from the pub cache, which every Flutter project on the machine shares. The per-project inputs (SERIOUS_PYTHON_APP, SERIOUS_PYTHON_SITE_PACKAGES) are fine; the shared copy they are staged into is not.

iOS and macOS (code at 16bceeb, identical to the published 5.0.0):

  1. The package command stages the processed app to SERIOUS_PYTHON_APP (per project), then runs prepare_spm.sh inside the plugin's darwin/ directory, which _resolveDarwinDir() finds through the project's package_config.json, i.e. in the pub cache:
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python/bin/package_command.dart#L593-L602
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python/bin/package_command.dart#L689-L741
  2. sync_site_packages.sh rsyncs $SERIOUS_PYTHON_APP into $script_dir/dist_ios/app and dist_macos/app, and the site-packages and the frameworks built from them into dist_ios/site-packages and dist_ios/site-xcframeworks:
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_darwin/darwin/sync_site_packages.sh#L9-L22
  3. Under Swift Package Manager (Flutter's default since 3.44), stage_spm.sh copies dist_ios/{stdlib,site-packages,app} into the package's Sources/serious_python_darwin/Resources/ and the extension frameworks into extra-xcframeworks/, which Package.swift bundles as .copy("Resources/app") and binary targets:
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_darwin/darwin/stage_spm.sh#L33-L48
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_darwin/darwin/serious_python_darwin/Package.swift#L94-L104
  4. Under CocoaPods, the podspec's resource bundle points at the same folder:
    https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_darwin/darwin/serious_python_darwin.podspec#L76-L82
  5. Xcode copies those folders into the app later, during flutter build, which takes minutes. Another project's package step in that window overwrites them, and the first build bundles the second one's app (and its site-packages and frameworks, which differ when the requirements differ).

Android has the same race, with a shorter window. serious_python_android's Gradle tasks write app.zip, stdlib.zip, sitepackages.zip and extract.zip to file("src/main/assets") and the native libraries to src/main/jniLibs/<abi>, paths relative to the plugin's project directory, which is its folder in the pub cache:
https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_android/android/build.gradle.kts#L151
https://github.com/flet-dev/serious-python/blob/16bceeb92851022aec9ad6ef24616a0831dc2ba6/src/serious_python_android/android/build.gradle.kts#L423-L454
AGP merges them into the APK later in the same Gradle run, so two Gradle builds whose preBuild and asset merge overlap can package each other's app.zip (or a half-written one). On the machine above, ~/.pub-cache/hosted/pub.dev/serious_python_android-5.0.0/android/src/main/assets/app.zip is simply the last app any project built.

Steps to reproduce

  1. Two Flet apps (or two copies of one) whose main.py differ, for example one that shows "A" and one that shows "B".
  2. Start flet build ios-simulator in both, a few seconds apart, with the default ~/.pub-cache.
  3. In each project compare the packaged app with what the bundle holds: 
    diff -rq build/python-app build/ios-simulator/*.app/serious_python_darwin_serious_python_darwin.bundle/app
    One of them reports the other project's files (only .keep should differ). Running both apps shows the same letter.

Workaround

A pub cache per project: PUB_CACHE=<project>/build/pub-cache flet build .... On APFS, mkdir -p build && cp -cR ~/.pub-cache build/pub-cache makes it in a few seconds without using disk space. With it, each bundle's app/ matched its own build/python-app/ (checked on iOS and Android).

Suggested fix

Stage per Flutter project, never in the plugin's own folder:

  • Android: write the generated zips and libraries under the plugin's Gradle build directory, which Flutter already places inside each app's build/, and add them as source directories, for example val assetsDir = layout.buildDirectory.dir("generated/serious_python/assets") with android.sourceSets["main"].assets.srcDir(assetsDir), and the same for jniLibs. No layout change for callers.
  • iOS and macOS: the app tree is the part that changes on every build, and a SwiftPM resource must live inside its package, so either:
    • take the app out of the plugin package: copy $SERIOUS_PYTHON_APP into the app bundle at build time (a script phase reading the variable that flet build already passes to flutter build), and let the runtime look for app/ there; or
    • stage into a per-project copy of the plugin's darwin/ directory (SERIOUS_PYTHON_DARWIN_DIR already overrides where staging happens) and have the caller point Flutter at that copy, e.g. flet build writing a dependency_overrides path under build/.
  • At least, detect it: record a hash of SERIOUS_PYTHON_APP when staging and compare it with what was bundled at the end of the build (or have flet build compare build/python-app with the bundle's app/), and fail with a clear message instead of shipping the wrong app.

Written by Claude Code (AI agent).

Vorherrschende Sprache
Dart
Sterne
325
Forks
46
Ø Merge
19 Std. 50 Min.
Gemergte PRs (30 T.)
4

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus flet-dev/serious-python

Alle Issues in flet-dev/serious-python

Ähnliche Issues

Weitere Issues zu Dart

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.