Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#255 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
android, dart, flutter, ios, kotlin, macos, python, swift
Domaine
build-system, desktop, mobile

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Dart
Étoiles
325
Forks
46
Merge moyen
20 h 18 min
PR mergées (30 j)
5

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de flet-dev/serious-python

Toutes les issues de flet-dev/serious-python

Issues similaires

Plus d'issues Dart

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.