Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do 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)

Aberta
  • Algo errado?
#255 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
android, dart, flutter, ios, kotlin, macos, python, swift
Domínio
build-system, desktop, mobile

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Dart
Estrelas
325
Forks
46
Merge médio
19h 50min
PRs com merge (30d)
4

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de flet-dev/serious-python

Todas as issues de flet-dev/serious-python

Issues semelhantes

Mais issues de Dart

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.