flet-dev
bug: flet build windows gets stuck on packaging python app; and extension template generation issues
Duplicate Check
- [x] I have searched the opened issues and there are no duplicates
Describe the bug
I have been following the documentation on creating user extensions for flet step-by-step from here. As of right now, I have managed to work my way through the following steps successfully[assuming that the flet extension is just called flet-wvr] :
- created a virtual environment within the project folder.
- activated the virtual environment using .venv\Scripts\activate.bat
- installed flet[all] {version: 0.28.3 according to
pip show} usingpip install flet[all]on it. - ran the command suggested by the docs with the name for my extension in place -
flet create --template extension --project-name flet-wvr. - cd-ed into the newly created examples directory, and further more into the flet_wvr_example directory within it.
and, this is where the problems begin. Firstly, I have noticed an issue with the way the pyproject.toml is generated, which causes an unbalanced quotes error, it'd be nice if this was fixed so that the template generated paths with \\ instead of just \. This would prevent the confusion a new developer might face when they encounter this issue. I had ended up doing this manually though and that resulted in the elimination of the unbalanced quotes error on my end. So, with that out of the way, lets move on to the other issue I've been facing -
trying to run flet build windows -v or flet build windows or flet build windows -vv are all met with -
- an attempt at the installation of flutter, which is always successful and finishes with the status
Flutter 3.29.2 installed ✅. - an attempt at running a subprocess that uses the dart.bat from the installed flutter alongside serious_python, to package the app. this is the step that fails to ever finish. it gets stuck on Packaging Python app... forever. In verbose mode it doesn't show any logs about where it is getting stuck either, the last log shown during verbose mode building process is the attempt to run a subprocess with the dart.bat and serious_python args, after that it just gets stuck forever. I have tested and waited for this to finish for 2+ hours at some point and I am very positive this is not an internet speed issue or anything of that kind. A screenshot of how it looks with the
-vv[most detailed output I could possibly provide] will be attached to this issue.
To fix this issue and debug it, I have tried the following:
- deleted the build dirs created inside the examples/flet_wvr_example folder and the one created outside, alongside the egg info file from src -> this does not change anything, building it again causes the same issue to occur. Nothing is changed in the slightest.
- deleted flutter itself from my local environment, I do not use flutter separately for development -- so the original flutter installation was also due to flet, and wasn't manual, but I deleted it to let flet install a newer version of Flutter, this has also failed to lead to any improvements in the situation. This just makes flet wait for longer to first install flutter before it starts building the package, and then it gets stuck in the exact same way.
- tried deleting the entire venv and project directory and starting from scratch -- also does not work, this problem seems to be persistent across venvs.
- tried downgrading[using flet == 0.26.0 instead], this leads to different verbose output messages, but the build process still gets stuck on the "Packaging Python app..." stage. The last verbose output includes flet trying to install collected packages.
- tried using uv instead of pip to make venvs and run these commands -- leads to the same exact issue, no change observed.
- tried installing a newer version of python, the latest one infact, though the old version I had was 3.12, now I have 3.13.5 -- this did not change anything either.
- tried updating my visual studio development with c++ tools, this has also not lead to any difference in the build command output.
- i've tried running build with the
--cleanup-appand--clear-cacheoptions with also no difference observed in the behavior. - I've tried using the command prompt in admin mode, whilst following the same exact steps outlined previously -- this also leads to no change of behavior.
- tried using WSL[Windows Subsystem for Linux] to no avail, which should've been obvious right away, considering the fact that
flet build windowsis only supported on Windows and no other platform including linux, so this was just a shot in the dark. this method funnily enough worked in the past when trying to build for android, but it is sad that I cannot use it to bypass the issues I have been facing, this time around. - tried using AI to figure out if there were any solutions it could think of, GPT just straight up gave me a summary of it's google searches about the topic, that were very much unrelated, keep in mind that I am running a very minimal flet template, from the docs, and that there should not be any dependency or code related issues, cuz this is all pre-generated and has worked for multiple other users. Gemini on the other hand, did help me debug this quite a bit, and the steps I took to debug it more deeply have been outlined in the next few points.
- I tried using ProcMon[Process Monitor -- A tool made to be used to see all the low level events taking place as a result of different apps on the device], I used two major filters:
12.1. Process Name is python.exe 12.2. Process Name is flet.exe
I decided to limit the filters to just these two, after testing out the results with more. These filters were sufficient enough to fetch the events taking place at a lower level due to the flet build command.
A brief/short description of my analysis of the ProcMon logs along with Gemini's help would be that -- A bunch of QueryInformation events were being issued by python.exe for addresses/paths that corresponded to pip-related files. A bunch of these events were SUCCESSes, and alot of others in between were BUFFER OVERFLOWs. This would keep going for a while, until at the very end, python.exe just started issuing CloseFile events for most of the previously accessed paths and then it'd get stuck in a loop trying to make a TCP connection -- create a thread -- and then exit the thread, repeatedly with nothing else happening while the build was still stuck on the "Packaging Python app..." step. I will attach some of my screenshots of the events described here, alongside this issue. From the analysis of all these events, what I ended up inferring; using some help from Gemini -- was that the issue being faced here, was related to long paths on windows, hence why the BUFFER_OVERFLOW results were coming in for a bunch of the events. I even tried switching my development to a folder inside the C: dir, instead of it being in subdirs, but even then the same issues were faced. I tried enabling LongPath support for windows by modifying the Registry using regedit on windows and set the value of LongPathsEnabled to 1 and restarted my computer, with not alot of change in the build process.
Description of the build directories :
-
External[Outside the
examplesdirectory]: It contained an empty folder by the name ofbdist.win-amd64and alibfolder withflet_wvrandflutterbeing subdirs within thelibfolder that contained the python and flutter files forflet_wvrrespectively. -
Internal[Inside the
examples/flet_wvr_exampledirectory]: It contained three folders -- namely.hash,flutterandsite-packages; withsite-packagesbeing completely empty[gemini described this to be the major issue, it said that the build process was successful at setting up the extension but got stuck at packaging the flet app alongside the python environment, just wanted to leave this in, incase it'd be of any help],.hashcontained a file named template-1 andfluttercontained a bunch of flutter related stuff in it. -
This was not really a fix for this issue, but rather a workaround, but it did indicate that the guess about the problem being caused due to path lengths might be right -- I tried using github-actions to build the template, it finished with success and created an artifact -- which was a .zip of the state the repo would've been in, if flet build was to be run locally, as instructed in the docs -- but when trying to unzip it on my platform, windows gave me the following error:
Error 0x80010135: Path too long.. So my development has basically been put to a halt entirely due to this issue; and I cannot even use workarounds to be able to develop it still.
I have already tried asking for help on the flet discord server, to no avail, alot of the people on there tried to help, but alot of them haven't faced this issue. This issue seems to be unique to certain windows 11 devices. I cannot really afford to try and reinstall windows, and it shouldn't have to be like that, I should be able to use a framework and fix the issues related to it, without having to reinstall my very operating system.. I have spent countless hours trying to find a fix for this, and I really hope that this issue will be looked at and answered with immediate attention. I do not ask for much, I know this is a free service you guys are providing to the community and I appreciate that but I would still like for it to be less error-prone for it to be usable enough on my front. Thanks, I hope this gets resolved fast! I'll try to see if I can fix the template pyproject.toml generation issue with the backslashes in a PR.
Code sample
Code
N/A [just built the template, no explicit code has been written]
To reproduce
This seems to be a device/installation specific issue, and not all devices can reproduce this for some reason, but here are the steps I took to have come across this issue -
- create a virtual environment within the project folder.
- activate the virtual environment using .venv\Scripts\activate.bat
- instal flet[all] {version: 0.28.3 according to
pip show} usingpip install flet[all]on it. - run the command suggested by the docs with the name for my extension in place -
flet create --template extension --project-name flet-wvr. - cd into the newly created examples directory, and further more into the flet_wvr_example directory within it.
- run
flet build windows -vv. - wait for the flutter installation to finish and observe the behavior of the
Packaging Python app..., if your device has the [whatever thing is causing this issue] -- it should get stuck at running the subprocess and not finish.
Expected behavior
I expected the app to finish building within 10 mins max, that is the feedback I've gotten from other developers working with flet. But instead it just gets stuck on the "Packaging Python app..." step.
Screenshots / Videos
Captures
Operating System
Windows
Operating system details
Windows 11
Flet version
0.28.3
Regression
I'm not sure / I don't know
Suggestions
- To fix the template pyproject.toml generation issue, just make it generate with paths having \ in general, since they are gonna be escaped to \ anyways.
- I am very certain that the
flet build windows -vvissue has something to do with the path limit on windows, despite me having enabled long paths using the registry variable, it still gave me the buffer overflow issue at the smallest path i could possibly get to[while for most users it works fine even with longer paths, or it doesn't work altogether]. It also gave me the same Path too long issue whilst unzipping my pre-built github actions based zip file. So -- a fix would need to prolly try and make the command independent of the length of paths; And, maybe working on trying to rework the template structure, such that it doesn't look for files that deep into the project structure.
Logs
Logs
[13:27:12] Ensure Flutter has desktop support enabled
Run subprocess: ['C:\\Users\\ketch\\flutter\\3.29.2\\bin\\flutter.bat', 'config', '--no-version-check',
'--suppress-analytics', '--enable-windows-desktop']
[13:27:13] Setting "enable-windows-desktop" value to "true".
You may need to restart any open editors for them to read new settings.
[13:27:14] Flutter 3.29.2 installed ✅
Flutter executable: C:\Users\ketch\flutter\3.29.2\bin\flutter.bat
Dart executable: C:\Users\ketch\flutter\3.29.2\bin\dart.bat
Run subprocess: ['C:\\Users\\ketch\\flutter\\3.29.2\\bin\\dart.bat', 'run', '--suppress-analytics',
'serious_python:main', 'package', 'C:\\adi_dev\\flet_extensions\\flet_wvr\\examples\\flet_wvr_example\\src',
'--platform', 'Windows', '-r', 'flet-wvr @ file://C:\\adi_dev\\flet_extensions\\flet_wvr', '-r',
'flet>=0.28.3', '-r', '--no-cache-dir', '--exclude', 'build', '--cleanup-packages', '--verbose']
(● ) Packaging Python app...
Additional details
For the most part, I have already gone over this and stressed this enough, but this happens only on some devices and not on others. It might just be a lack of knowledge on my end, but I'd like to know about how to fix this either way, and if it helps others out it'd be even better, which is why I have decided to post this as an issue.
@Jarzamendia Just to confirm a suspicion I might have about this bug, may I ask you if you also have anaconda installed on your windows 11? or do you just have base python? I have a sneaky suspicion that having an anaconda installation might be the cause, but I wanna make sure its not just me who has one and is facing this issue.
I finally found some logs being generated within the build/flutter folder, in a file named 0.28.3, the logs are as follows:
Running package command
Extra PyPi indexes: [https://pypi.flet.dev]
Created temp directory: C:\Users\ketch\AppData\Local\Temp\serious_python_temp8cc0099b
Copying Python app from C:\dev\examples\flet_splinkit_example\src to a temp directory
VERBOSE: Configured Windows/ platform with sitecustomize.py at C:\Users\ketch\AppData\Local\Temp\serious_python_sitecustomize66c2c9aa\sitecustomize.py
Installing [flet-splinkit @ file://C:\dev, flet, --no-cache-dir] with pip command to C:\dev\examples\flet_splinkit_example\build\site-packages
VERBOSE: C:\dev\examples\flet_splinkit_example\build\flutter\build\build_python_3.12.9\python\python.exe -m pip install --upgrade --disable-pip-version-check --extra-index-url https://pypi.flet.dev --target C:\dev\examples\flet_splinkit_example\build\site-packages flet-splinkit @ file://C:\dev flet --no-cache-dir
VERBOSE: Looking in indexes: https://pypi.org/simple, https://pypi.flet.dev
Processing c:\dev
VERBOSE: Installing build dependencies: started
VERBOSE: Installing build dependencies: finished with status 'done'
VERBOSE:
VERBOSE: Getting requirements to build wheel: started
VERBOSE:
VERBOSE: Getting requirements to build wheel: finished with status 'done'
VERBOSE: Preparing metadata (pyproject.toml): started
VERBOSE:
VERBOSE: Preparing metadata (pyproject.toml): finished with status 'done'
VERBOSE: Collecting flet
VERBOSE:
VERBOSE: Downloading flet-0.28.3-py3-none-any.whl.metadata (3.6 kB)
VERBOSE: Collecting httpx (from flet)
VERBOSE:
VERBOSE: Downloading httpx-0.28.1-py3-none-any.whl.metadata (7.1 kB)
VERBOSE:
VERBOSE: Collecting oauthlib<4.0.0,>=3.2.2 (from flet)
VERBOSE: Downloading oauthlib-3.3.1-py3-none-any.whl.metadata (7.9 kB)
VERBOSE: Collecting repath<0.10.0,>=0.9.0 (from flet)
VERBOSE:
VERBOSE: Downloading repath-0.9.0-py3-none-any.whl.metadata (899 bytes)
VERBOSE:
VERBOSE: Collecting six>=1.9.0 (from repath<0.10.0,>=0.9.0->flet)
VERBOSE: Downloading six-1.17.0-py2.py3-none-any.whl.metadata (1.7 kB)
VERBOSE: Collecting anyio (from httpx->flet)
VERBOSE: Downloading anyio-4.9.0-py3-none-any.whl.metadata (4.7 kB)
VERBOSE:
VERBOSE: Collecting certifi (from httpx->flet)
VERBOSE:
VERBOSE: Downloading certifi-2025.7.14-py3-none-any.whl.metadata (2.4 kB)
VERBOSE:
VERBOSE: Collecting httpcore==1.* (from httpx->flet)
VERBOSE:
VERBOSE: Downloading httpcore-1.0.9-py3-none-any.whl.metadata (21 kB)
VERBOSE:
VERBOSE: Collecting idna (from httpx->flet)
VERBOSE:
VERBOSE: Downloading idna-3.10-py3-none-any.whl.metadata (10 kB)
VERBOSE:
VERBOSE: Collecting h11>=0.16 (from httpcore==1.*->httpx->flet)
VERBOSE: Downloading h11-0.16.0-py3-none-any.whl.metadata (8.3 kB)
VERBOSE: Collecting sniffio>=1.1 (from anyio->httpx->flet)
VERBOSE:
VERBOSE: Downloading sniffio-1.3.1-py3-none-any.whl.metadata (3.9 kB)
VERBOSE:
VERBOSE: Collecting typing_extensions>=4.5 (from anyio->httpx->flet)
VERBOSE:
VERBOSE: Downloading typing_extensions-4.14.1-py3-none-any.whl.metadata (3.0 kB)
VERBOSE:
VERBOSE: Downloading flet-0.28.3-py3-none-any.whl (463 kB)
VERBOSE: Downloading oauthlib-3.3.1-py3-none-any.whl (160 kB)
VERBOSE:
VERBOSE: Downloading repath-0.9.0-py3-none-any.whl (4.7 kB)
VERBOSE: Downloading httpx-0.28.1-py3-none-any.whl (73 kB)
VERBOSE:
VERBOSE: Downloading httpcore-1.0.9-py3-none-any.whl (78 kB)
VERBOSE:
VERBOSE: Downloading six-1.17.0-py2.py3-none-any.whl (11 kB)
VERBOSE:
VERBOSE: Downloading anyio-4.9.0-py3-none-any.whl (100 kB)
VERBOSE:
VERBOSE: Downloading idna-3.10-py3-none-any.whl (70 kB)
VERBOSE:
VERBOSE: Downloading certifi-2025.7.14-py3-none-any.whl (162 kB)
VERBOSE:
VERBOSE: Downloading h11-0.16.0-py3-none-any.whl (37 kB)
VERBOSE:
VERBOSE: Downloading sniffio-1.3.1-py3-none-any.whl (10 kB)
VERBOSE:
VERBOSE: Downloading typing_extensions-4.14.1-py3-none-any.whl (43 kB)
VERBOSE: Building wheels for collected packages: flet-splinkit
VERBOSE:
VERBOSE: Building wheel for flet-splinkit (pyproject.toml): started
VERBOSE:
VERBOSE: Building wheel for flet-splinkit (pyproject.toml): finished with status 'done'
VERBOSE: Created wheel for flet-splinkit: filename=flet_splinkit-0.1.0-py3-none-any.whl size=4659 sha256=451b84b2d1789e16c87f777e44285c471d483df5654868fccbce989150258019
Stored in directory: C:\Users\ketch\AppData\Local\Temp\pip-ephem-wheel-cache-css_r6m4\wheels\c4\16\4f\32a6c9c0806abcc0340027a493c9ccffa4fba70de10fd71a2a
VERBOSE: Successfully built flet-splinkit
VERBOSE: Installing collected packages: typing_extensions, sniffio, six, oauthlib, idna, h11, certifi, repath, httpcore, anyio, httpx, flet, flet-splinkit
VERBOSE:
it always generates logs till here and gets stuck on this step, can this help in any way to solve the issue? @FeodorFitsner @ndonkoHenri
I tried running the command it is trying to run, manually, and it worked really quickly and the site-packages folder was filled up with all the files needed, but it doesn't work when it executes it and it gets stuck on the installing stage. is there a way to fix this? i have tried setting PYTHONUTF8 to 1 within the console incase it was because of that. I also tried running flet build windows -vv right after running the command from the logs, but it completely erases everything and works from scratch, so it did not work out.
I have already tried disabling windows defender[the only antivirus I have], and it didn't change anything, I have also checked process explorer[a tool from microsoft sys internals], and it doesn't show any blockades for the site-packages folder path either.
Yo tenia el mismo problema , te recomiendo lo siguiente : Intenta crear tu proyecto usando poetry para mi fue la solución al crear usar flet build windows y que se congelara sigue los pasos para crear un nuevo proyecto que esta en la documentación https://flet.dev/docs/getting-started/#poetry esto te ayuda a generar la estructura de directorios correcta y el entorno virtual
@Jarzamendia Just to confirm a suspicion I might have about this bug, may I ask you if you also have anaconda installed on your windows 11? or do you just have base python? I have a sneaky suspicion that having an anaconda installation might be the cause, but I wanna make sure its not just me who has one and is facing this issue.
No, only Python 3.12.6 and pip 24.2.
I'll try the poetry method!
After running some tests, I was able to successfully build the Windows app. I had to remove a few dependencies, which led me to identify the issue as being related to the wheel build process during the installation of certain Python packages.
In this case, the problem occurred with the Pillow package during installation.
However, the process doesn't seem to provide logs or output messages, which makes troubleshooting a bit challenging.
@Razielthc It did not work. I tried it and its still stuck on packaging python app, I am thinking of just trying wsl with linux builds at this point... Also, @Jarzamendia im glad ur issue got solved! I doubt mine is the same issue though cuz I do not even have any extra dependencies, this is just base flet
Thanks so much for your help guys! Sadly the devs have decided to completely ignore this bug report for some reason :/ It feels like most of the build related bugs get ignored. Maybe they themselves don't know how to fix this, or just do not care enough.. This is sadly also whats bringing this framework down as a whole for me.. whats the point of being able to write nice UI design up if you cannot even actually build it into an app for distribution.. its just stupid.
@typedecker Your report includes a lot of helpful details — thank you for that. However, it actually contains two separate issues:
-
flet buildstuck - Extension generation issue
To keep things organized and easier to track, please open each problem as its own issue.
For the first problem (flet build stuck), we still don’t have enough information to investigate:
- Full build log
- List of installed Python packages
Once you provide these details in a separate issue, we’ll be able to help more effectively.
If you’re not hearing back from the Flet team right away, it’s simply because we’re a small group and are heads-down polishing and preparing the Flet 1.0 release. Right now, support for flet build issues has slightly lower priority because:
- Every setup is different – Build problems are often unique to each developer’s environment. Flutter itself has many moving parts, and builds can be tricky, especially on Windows (Defender, Developer Mode, long file paths, missing VS 2022 components, etc.).
- A better way is coming – Later this year, we’ll launch a packaging service for multiple platforms, with a standardized environment and workflow to make builds more predictable and easier to troubleshoot.
We truly appreciate the time you’ve spent digging into your issue — that kind of effort helps make Flet better for everyone. As an open-source project, Flet is built and maintained by contributors, often in their free time. While we do our best to help, there’s no guaranteed support, so we rely heavily on community contributions, shared solutions, and patience from everyone involved.
...just a thought - try running flet build for your project in a clean environment, such as fresh Windows Azure VM with just VS 2022 installed or GitHub Actions job.
@FeodorFitsner I have tried github actions already, but they get stuck on some flutter header error for some reason :/ I cannot afford to install windows from scratch cuz of personal reasons. Do you have any guesses on why this is happening though? since you know how things work on the backend
Also I just read the other message you've sent! Thanks for replying! I am sorry if it came off really rudely.. I've just been working on this issue for a while and I really wanna help this framework grow in every way possible, I have even come up with an ID system for controls and a XML to flet component parser script as well! I might also work on some drag and drop based program for flet later, once I have fleshed out the XML parser and my other apps! This issue has just been keeping me from using extensions, but I am willing to wait for 1.0's release, if it brings a better build system, I'd be very very happy to wait for however long it might take! Sorry for the impatience I demonstrated earlier.
Also to answer your questions and concerns on the build and the issue in general -- I shall make a separate issue for the extension generation process 👍, we can have this as the issue related to just flet build in general instead. I just have seen alot of people facing the flet build windows getting stuck on packaging python apps.. issue, and I really wanted to try my best to find the root cause of this.
- As for the build logs, I have already attached the main build logs to the main issue's logs section, and also there were some extra logs that I found in a file named 0.28.3 within the flutter folder, after the build got stuck -- I had sent these in a comment, but I can resend them here for convenience <33 :
Running package command
Extra PyPi indexes: [https://pypi.flet.dev]
Created temp directory: C:\Users\ketch\AppData\Local\Temp\serious_python_temp8cc0099b
Copying Python app from C:\dev\examples\flet_splinkit_example\src to a temp directory
VERBOSE: Configured Windows/ platform with sitecustomize.py at C:\Users\ketch\AppData\Local\Temp\serious_python_sitecustomize66c2c9aa\sitecustomize.py
Installing [flet-splinkit @ file://C:\dev, flet, --no-cache-dir] with pip command to C:\dev\examples\flet_splinkit_example\build\site-packages
VERBOSE: C:\dev\examples\flet_splinkit_example\build\flutter\build\build_python_3.12.9\python\python.exe -m pip install --upgrade --disable-pip-version-check --extra-index-url https://pypi.flet.dev --target C:\dev\examples\flet_splinkit_example\build\site-packages flet-splinkit @ file://C:\dev flet --no-cache-dir
VERBOSE: Looking in indexes: https://pypi.org/simple, https://pypi.flet.dev
Processing c:\dev
VERBOSE: Installing build dependencies: started
VERBOSE: Installing build dependencies: finished with status 'done'
VERBOSE:
VERBOSE: Getting requirements to build wheel: started
VERBOSE:
VERBOSE: Getting requirements to build wheel: finished with status 'done'
VERBOSE: Preparing metadata (pyproject.toml): started
VERBOSE:
VERBOSE: Preparing metadata (pyproject.toml): finished with status 'done'
VERBOSE: Collecting flet
VERBOSE:
VERBOSE: Downloading flet-0.28.3-py3-none-any.whl.metadata (3.6 kB)
VERBOSE: Collecting httpx (from flet)
VERBOSE:
VERBOSE: Downloading httpx-0.28.1-py3-none-any.whl.metadata (7.1 kB)
VERBOSE:
VERBOSE: Collecting oauthlib<4.0.0,>=3.2.2 (from flet)
VERBOSE: Downloading oauthlib-3.3.1-py3-none-any.whl.metadata (7.9 kB)
VERBOSE: Collecting repath<0.10.0,>=0.9.0 (from flet)
VERBOSE:
VERBOSE: Downloading repath-0.9.0-py3-none-any.whl.metadata (899 bytes)
VERBOSE:
VERBOSE: Collecting six>=1.9.0 (from repath<0.10.0,>=0.9.0->flet)
VERBOSE: Downloading six-1.17.0-py2.py3-none-any.whl.metadata (1.7 kB)
VERBOSE: Collecting anyio (from httpx->flet)
VERBOSE: Downloading anyio-4.9.0-py3-none-any.whl.metadata (4.7 kB)
VERBOSE:
VERBOSE: Collecting certifi (from httpx->flet)
VERBOSE:
VERBOSE: Downloading certifi-2025.7.14-py3-none-any.whl.metadata (2.4 kB)
VERBOSE:
VERBOSE: Collecting httpcore==1.* (from httpx->flet)
VERBOSE:
VERBOSE: Downloading httpcore-1.0.9-py3-none-any.whl.metadata (21 kB)
VERBOSE:
VERBOSE: Collecting idna (from httpx->flet)
VERBOSE:
VERBOSE: Downloading idna-3.10-py3-none-any.whl.metadata (10 kB)
VERBOSE:
VERBOSE: Collecting h11>=0.16 (from httpcore==1.*->httpx->flet)
VERBOSE: Downloading h11-0.16.0-py3-none-any.whl.metadata (8.3 kB)
VERBOSE: Collecting sniffio>=1.1 (from anyio->httpx->flet)
VERBOSE:
VERBOSE: Downloading sniffio-1.3.1-py3-none-any.whl.metadata (3.9 kB)
VERBOSE:
VERBOSE: Collecting typing_extensions>=4.5 (from anyio->httpx->flet)
VERBOSE:
VERBOSE: Downloading typing_extensions-4.14.1-py3-none-any.whl.metadata (3.0 kB)
VERBOSE:
VERBOSE: Downloading flet-0.28.3-py3-none-any.whl (463 kB)
VERBOSE: Downloading oauthlib-3.3.1-py3-none-any.whl (160 kB)
VERBOSE:
VERBOSE: Downloading repath-0.9.0-py3-none-any.whl (4.7 kB)
VERBOSE: Downloading httpx-0.28.1-py3-none-any.whl (73 kB)
VERBOSE:
VERBOSE: Downloading httpcore-1.0.9-py3-none-any.whl (78 kB)
VERBOSE:
VERBOSE: Downloading six-1.17.0-py2.py3-none-any.whl (11 kB)
VERBOSE:
VERBOSE: Downloading anyio-4.9.0-py3-none-any.whl (100 kB)
VERBOSE:
VERBOSE: Downloading idna-3.10-py3-none-any.whl (70 kB)
VERBOSE:
VERBOSE: Downloading certifi-2025.7.14-py3-none-any.whl (162 kB)
VERBOSE:
VERBOSE: Downloading h11-0.16.0-py3-none-any.whl (37 kB)
VERBOSE:
VERBOSE: Downloading sniffio-1.3.1-py3-none-any.whl (10 kB)
VERBOSE:
VERBOSE: Downloading typing_extensions-4.14.1-py3-none-any.whl (43 kB)
VERBOSE: Building wheels for collected packages: flet-splinkit
VERBOSE:
VERBOSE: Building wheel for flet-splinkit (pyproject.toml): started
VERBOSE:
VERBOSE: Building wheel for flet-splinkit (pyproject.toml): finished with status 'done'
VERBOSE: Created wheel for flet-splinkit: filename=flet_splinkit-0.1.0-py3-none-any.whl size=4659 sha256=451b84b2d1789e16c87f777e44285c471d483df5654868fccbce989150258019
Stored in directory: C:\Users\ketch\AppData\Local\Temp\pip-ephem-wheel-cache-css_r6m4\wheels\c4\16\4f\32a6c9c0806abcc0340027a493c9ccffa4fba70de10fd71a2a
VERBOSE: Successfully built flet-splinkit
VERBOSE: Installing collected packages: typing_extensions, sniffio, six, oauthlib, idna, h11, certifi, repath, httpcore, anyio, httpx, flet, flet-splinkit
VERBOSE:
The build logs stop here, and do not continue past this. Trying to install these pip packages manually using the pip instance the cli script was using, works, but for some reason the script itself cannot do it :/ this might be a serious python issue.
- The only installed package was flet, everything else was just installed automatically by flet if needed.
Also, I had a look at v1.0 docs, great job with them honestly! I would love to contribute in any way possible with docs too, I love documenting things in as informative of a way as possible <33 Thanks! @FeodorFitsner
Thanks, 1.0 is the way to go! Contributors are always welcome!
Are you able to share your project by chance? If it's closed-source maybe you can provide me steps to reproduce starting for extension creation?
@FeodorFitsner Yes! I can't wait for 1.0, do yall have any audio-service playback in the background features planned by any chance?
Also, If by project you meant the extension creation project that I have been having trouble with, its basically just done with me following all the steps provided in the extension creation docs but for windows instead! It all works until when I run flet build windows -vv, thats when it all goes wrong -- it gets to the Packaging python app stage but doesn't go further than that, and my issue report details all the processes that ProcMon[A useful windows tool] can see happening during the packaging, and where exactly it stops. I also found a file named 0.28.3 with some pip install logs, as I mentioned in my previous comment, which leads me to believe that this is in some way related to serious python or the automatic installation of site-packages in the build directory, cuz its completely empty the whole time, and the pip install gets stuck on installing collected packages[check the last line of the log I sent]
Have you tried building it with flet build windows -v (one -v - less detailed log)?
yes I have, I have tried with -v, -vv, and --verbose, it fails in all cases with the same logs
OK, I will follow steps in https://flet.dev/docs/extend/user-extensions to see if it works on Windows.
I think it works for some people, and not for others, so it might have something to do with the installation/platform itself, though I cannot exactly pinpoint what the issue is, but flet build just doesn't work for me at all, whether it be flet build windows or flet build apk, it always gets stuck on "Packaging python apps...", so maybe if you're aware of the way the flet app gets packaged and built and the steps that are taken internally by the CLI, you could pinpoint where its going wrong -- considering that the pip install logs stopped at installing collected packages, i think the flutter part of all this works, but it cannot transfer the site packages over to the build dir folder, thats my guess on why this is happening, but idk why it cannot copy things over and i have no way of knowing it either, cuz it doesnt show any reason as to why it cannot install the packages. I can also record the entire process and send it as a video if you'd like.
Even if this only happens on some devices and not every device, I feel like it'd be great if this gets fixed, I'd be able to build so much more with flet and I genuinely would be really grateful!
I would've tried it on a separate windows installation, but I cannot really spinup a windows vm right now, since it takes up alot of space and I also cannot factory reset my computer right now, so I did the next best thing and reinstalled python entirely, but even that didn't fix this.
@RazielthcNo funcionó. Lo probé y sigue bloqueado al empaquetar la aplicación de Python. Estoy pensando en probar WSL con compilaciones de Linux ahora mismo... Además,@Jarzamendia¡Me alegra que tu problema se haya resuelto! Dudo que el mío sea el mismo, porque ni siquiera tengo dependencias adicionales; este es solo el archivo base.
Intenta de nuevo y asegúrate de seguir lo siguiente después de crear el proyecto y tener la estructura de carpetas correcta crea un requirements.txt de forma manual dentro del src y agrega las librerias de forma manual como el siguiente ejemplo
ingresa dentro de src y ejecuta el poetry run flet build --vv
tu pyproject.toml debe tener algo como esto
esto funciono para my
[project]
name = "dec-barrancon"
version = "0.1.0"
description = ""
readme = "README.md"
requires-python = ">=3.9,<4.0"
authors = [
{ name = "Flet developer", email = "[email protected]" }
]
dependencies = [
"fletx",
"flet==0.28.3",
"python-dotenv>=1.1.1,<2.0.0",
"supabase>=2.17.0,<3.0.0",
]
[tool.flet] app.module = "main" app.path = "src" assets_dir = "src/assets" # Ruta a tus assets include_dirs = ["storage"] # Directorios adicionales a incluir
Configuración de compilación (opcional)
compile.app = true compile.packages = true org = "MIS Soluciones en Tecnologia" product = "dec-barrancon" company = "Flet" copyright = "Copyright (C) 2025 by Flet"
[tool.uv] dev-dependencies = [ "flet[all]==0.28.3", ]
[tool.poetry] package-mode = false
[tool.poetry.group.dev.dependencies] flet = {extras = ["all"], version = "0.28.3"}
@RazielthcNo funcionó. Lo probé y sigue bloqueado al empaquetar la aplicación de Python. Estoy pensando en probar WSL con compilaciones de Linux ahora mismo... Además,@Jarzamendia¡Me alegra que tu problema se haya resuelto! Dudo que el mío sea el mismo, porque ni siquiera tengo dependencias adicionales; este es solo el archivo base.
Intenta de nuevo y asegúrate de seguir lo siguiente después de crear el proyecto y tener la estructura de carpetas correcta crea un requirements.txt de forma manual dentro del src y agrega las librerias de forma manual como el siguiente ejemplo
ingresa dentro de src y ejecuta el poetry run flet build --vv
tu pyproject.toml debe tener algo como esto
esto funciono para my
[project] name = "dec-barrancon" version = "0.1.0" description = "" readme = "README.md" requires-python = ">=3.9,<4.0" authors = [ { name = "Flet developer", email = "[email protected]" } ] dependencies = [ "fletx", "flet==0.28.3", "python-dotenv>=1.1.1,<2.0.0", "supabase>=2.17.0,<3.0.0",
]
[tool.flet] app.module = "main" app.path = "src" assets_dir = "src/assets" # Ruta a tus assets include_dirs = ["storage"] # Directorios adicionales a incluir
Configuración de compilación (opcional)
compile.app = true compile.packages = true org = "MIS Soluciones en Tecnologia" product = "dec-barrancon" company = "Flet" copyright = "Copyright (C) 2025 by Flet"
[tool.uv] dev-dependencies = [ "flet[all]==0.28.3", ]
[tool.poetry] package-mode = false
[tool.poetry.group.dev.dependencies] flet = {extras = ["all"], version = "0.28.3"}
I am not using supabase, or fletx, i just need to make an extension for base flet. I have already tried poetry and it did not work, I have the correct folder structure as well. I didnt rly make any of the folders myself, flet made it on it's own when I ran the template generation command. I shall still try the requirements.txt suggestion, eventhough I doubt it'll make any difference or will even work for extensions. But thanks for the help!
Also just tried the requirements.txt suggestion -- did not work either. I have also just tried clearing up my temp folder within app data hoping that it might've fixed things if that was what the cause was, but it seems like it wasn't. Also for anyone going through or trying to help solve this issue, I'd strongly suggest going through the description of my issue in the main issue post before you try and suggest workarounds -- a majority of them have already been tried out and the outputs and results are all mentioned and provided here.. so its a little redundant and a waste of time, to go in circles answering questions about what has already been tried. Thanks! I hope you all understand <3
I can confirm this issue, I am facing the same. Extending Flet with custom components is currently not stable for Windows 11.
As Feodor has mentioned:
Every setup is different – Build problems are often unique to each developer’s environment. Flutter itself has many moving parts, and builds can be tricky, especially on Windows (Defender, Developer Mode, long file paths, missing VS 2022 components, etc.). A better way is coming – Later this year, we’ll launch a packaging service for multiple platforms, with a standardized environment and workflow to make builds more predictable and easier to troubleshoot.
I would suggesting sunsetting it now before you get more bug reports about it that stem all from the same issue, which most likely won't receive a fix until the new Flet 1.0.0 release.
OK, to test building of Flet extension from scratch I created a new repo with GitHub Actions workflow on Windows which creates a new extension project according to the guide and builds its example with flet build.
There was an issue with Windows paths in extension template for 0.28.3, but after I fixed it and updated template the build worked like a charm.
Here's the repo: https://github.com/FeodorFitsner/flet-extension-build Workflow definition: https://github.com/FeodorFitsner/flet-extension-build/blob/main/.github/workflows/flet-extension-windows.yml - you can see all commands used to setup environment and build the app. Workflow run: https://github.com/FeodorFitsner/flet-extension-build/actions/runs/16946434302/job/48028475177
Built Windows app (I published it to releases from workflow artifacts): https://github.com/FeodorFitsner/flet-extension-build/releases/tag/10
I tested the app on my Windows 11 machine and it worked just fine:
Now, you can take that repo and workflow as the baseline and adjust it to your need to see what causes hanging.
Thanks for the github workflow repo feodor! I'll make sure to give the github workflow method another try with your workflow definition and report back on how it goes for me asap <33! Though as I stated previously, this is a conditional problem that seems to not happen for everyone and only specifically on certain devices running windows 11, and as you can tell from all the debugging attempts -- its basically impossible to tell whats going on without more logs being provided by the CLI. I have tried my best to debug this and I feel like it runs into some kind of issue tryna copy over the site packages from the pip cache folders in Appdata/Local/Temp to the site-packages folder within the build/flutter folder. When run on singular verbose mode: -v it produces a file named 1.1.1 which also has similar logs to the 0.28.3 log file described earlier. The github workflow might be a temporary fix for me personally if it works, but I'd still request you to look into the logs I've provided to see if you could spot a potential flaw in the execution of the command and spot the reason behind this issue, cuz if this gets fixed in the coming versions of flet, it'd be very useful :D!
I can confirm this issue, I am facing the same. Extending Flet with custom components is currently not stable for Windows 11.
As Feodor has mentioned:
Every setup is different – Build problems are often unique to each developer’s environment. Flutter itself has many moving parts, and builds can be tricky, especially on Windows (Defender, Developer Mode, long file paths, missing VS 2022 components, etc.). A better way is coming – Later this year, we’ll launch a packaging service for multiple platforms, with a standardized environment and workflow to make builds more predictable and easier to troubleshoot.
I would suggesting sunsetting it now before you get more bug reports about it that stem all from the same issue, which most likely won't receive a fix until the new Flet 1.0.0 release.
I am totally fine with this approach as well <33 As long as I can find a temporary fix for now, and a promising future for flet's build systems in the coming weeks and months, I would love to close out this issue!
Also, I was just checking out the github workflow instructions for the extension building -- has it been designed to just give back the artifact as just the stuff within the build folder? and if so, what would I have to do to be able to then use this artifact to test the extension using just flet run on my device? is copying the build folder into my existing extension template enough? or should I modify the workflow to instead return the entire extension folder back as an artifact and then use that for development?
Yes, when you run flet run it first checks {project_dir}/build/windows/*.exe, so if you build that exe with GitHub Actions, download and extract it there it will be picked up by flet run. Is this your question?