Repository navigation
Pin flet and its extensions to the Flet CLI version when building and publishing - #7047
Open
ndonkoHenri wants to merge 3 commits into
Open
ndonkoHenri wants to merge 3 commits into
ndonkoHenri wants to merge 3 commits into
Conversation
… publishing `flet build`, `flet debug` and `flet publish` produce an app that runs in a Flet client of the CLI's version, but installed the app's dependencies as declared. `flet create` declares `flet>=<version>`, so pip, and micropip on every page load of a published site, picked the newest release and the app failed at runtime on anything that release changed, while `flet run` kept working. `flet` and the packages released with it are now pinned to the CLI's version, keeping extras and markers. A requirement that excludes that version stops the command with an explanation. Nothing is pinned when `flet` itself comes from a path or URL, such as `dev_packages`. A `requirements.txt` with hashes is only checked, because pip rejects requirements without a hash. `flet publish` also adds `[tool.flet.web].dependencies` to the archive's requirements. An extension listed only there would otherwise ask for a newer `flet` on page load, and an app in a subdirectory never installed them at all.
Testing on real projects and two reviews found requirement forms that the pin got wrong: - A conflicting requirement with an environment marker no longer stops the command, because it may not apply to the target. pip decides. - `flet` from a local checkout, a bare wheel filename, or a location followed by extras or a marker is left alone instead of getting a clashing pin. - `requirements.txt` files with a byte order mark, including the UTF-16 that older PowerShell writes, are decoded, so their requirements get pinned. - A `-r` inside a constraints file is read as requirements, and `file:` includes are read, as pip does. No `flet` pin is added next to any other URL include, which can't be read here. - `--hash` in a comment no longer turns off the pin. Also list `FLET_PACKAGES` in the extension checklist.
Deploying flet-website-v2 with
|
| Latest commit: |
2356711
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://3953c7a5.flet-website-v2.pages.dev |
| Branch Preview URL: | https://fix-pin-flet-to-cli-version.flet-website-v2.pages.dev |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #6894. A built app runs in a Flet client of the CLI's version, but its Python packages were installed as declared.
flet createwritesflet>=<version>, so a build, or a published site on every page load, could get a newerfletthan its client and fail at runtime on anything that release changed, whileflet runkept working.What changes
flet build,flet debug,flet testandflet publishnow installfletand the packages released with it at the CLI's version. Extras and markers are kept.flet>=1.0.5fletflet==1.1.0flet-chartsflet-chartsflet-charts==1.1.0flet==0.86.3fletfrom a path or URL, e.g.dev_packagesrequirements.txt: pip reads the file itself, so pins go next to it. A file using hashes is only checked, because pip rejects requirements without a hash.flet publish: also adds[tool.flet.web].dependenciesto the archive's requirements, and checks for conflicts before it clearsdist. An extension listed only there would otherwise ask for a newerfleton page load, and an app in a[tool.flet.app].pathsubdirectory never installed them.Please look at
FLET_PACKAGESis a new list to keep in sync. pip alone doesn't need it, but micropip does: with onlyfletpinned, a published site with an unpinned extension fails at startup once a newer release is out (reproduced in Chrome). A test fails if a folder insdk/python/packagesis missing from it, and it's in the extension checklist.flet, such asflet==1.0.4under a 1.0.5 CLI, used to build and now stops. A third-party package that requires anotherfletversion now fails in pip's resolver. Both used to ship the mismatch this fixes.flet-notificationsandflet-shadcn-uihave no 1.0.x releases.Limits
flet>=1.0.5should bundle 1.1.0 once it's out.-cconstraints file ends in pip's error rather than ours.flet = "^0.86.3"in Poetry is read as>=0.86.3, an existing bug, so it gets pinned instead of raising the conflict.Testing
CLI
1.1.0.dev4from source, Flutter 3.47.9:flet createapp:build macos, then launchedflet debug macos,flet test macosbuild apk, installed and launchedbuild ios-simulator, installed and launchedbuild webon 19 project shapes: ranges, extras, markers, Poetry, no deps, BOM, UTF-16, nested files, conflicts, local packagesrequirements.txt, markers, web-only extensionfletandflet-chartsat 1.0.4build windows(launched, window opened),build webwith markers throughdart.bat, UTF-16 file, conflicttest_warns_when_listed_file_is_missing, in a file this PR doesn't touchbuild linux,build web, conflicttest_run_assets_dir[web], needsflet-web, which wasn't installed thereThree web shapes failed the same way on unmodified 1.1.0.dev4:
flet[all]on web,--no-cache-dirinrequirements.txt, and./mylibin[project].dependencies. A localfletcheckout next to an unpinned extension also fails in pip's resolver; the pin leaves that list as declared.Not run: signed release builds (
ipa,aab), x64 Windows. The last fixes, for--hashin comments andfile:includes, have unit tests on all three systems and real web builds on macOS only. The Windows desktop app showed a firewall prompt for Python on first launch; I left it unanswered and didn't compare it against a build without this change.Reviewed by Codex twice and Claude once. Findings are fixed except the limits above.
Summary by Sourcery
Align packaged Flet dependencies with the CLI version across build and publish workflows to prevent client and Python package incompatibilities.
Bug Fixes:
Enhancements:
Documentation:
Tests: