Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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)

Abierto
  • ¿Algo no está bien?
#255 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, dart, flutter, ios, kotlin, macos, python, swift
Área
build-system, desktop, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Dart
Estrellas
325
Forks
46
Merge medio
19 h 50 min
PR fusionados (30 d)
4

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de flet-dev/serious-python

Todos los issues de flet-dev/serious-python

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.