Guidance on v1.0 Migration, Multiprocessing Roadmap, and Packaging Best Practices

[ap4499]

Migration Strategy
With the transition to Flet 1.0, many of us are wondering about the best strategy for our existing Flet 0.x projects. Is Flet 0.7.x a recommended starting point for a rewrite, or are there other considerations we should be aware of? The key rationale for asking is that it feels counterproductive to start adding features into the deprecated framework.

Key question:

• is Flet 0.7x suitable to start the migration from?

Multiprocessing support
I've looked into the source code for the Flet elements and concluded that it is fundamentally difficult to implement a fix to enable Multiprocessing without endorsement from the core devs (given the development pipeline - and where the fixes would need to go at a fundamental architecture level). There are multiple options, and I think the one that retains the Flet simplicity, might be to open up the option to bundle a Python interpreter that can be targeted for Multiprocessing tasks - thus removing the need for an architecture shift, which could complicate mobile - but also achieves the goal of opening up options on desktop. This also seems to be where you are heading with Flet in terms of "services".

While this is going to result in 20-50MB larger application sizes than a more complex approach would require, most developers of high performance applications are probably comfortable with this trade-off, and one I think end users of such applications will be invariant to.

Then, the code could be:

from flet_services import flet_multiprocessing
worker_path = flet_multiprocessing()
multiprocessing.set_executable(worker_path)

Are there any plans to implement this? It is a significant barrier to many applications - particularly those where there are CPU bound tasks, or even processing demanding single threaded tasks that are causing GIL/GUI performance issues even when handled with asyncio (a known GIL limitation - rather than a Flet specific one).

Packaging
Also, with regards to Flet1.0 and packaging.. is there a roadmap to work on some stable and best practice workflows? Currently, packaging and the changes between versions have become a considerable development consideration (although, things are moving in a better general direction). Things like zipping up Flet-Desktop are challenging for notarization as it needs to be unzipped before it can be notarized, and then rezipped - it makes any Xcode integration very challenging, and it ends up requiring substantial custom scripting whatever path is chosen.

MacOS is particularly difficult to package for, and Apple themselves do have a significant role here (summarised well by the developer of "AltTab" for MacOS https://alt-tab-macos.netlify.app/contributing. "Documentation is abysmal. Very simple things are not documented at all, and good information is hard to find.").

Generally, I feel that the best approach might be to move towards a position where Flet has the requisite cli options, and then feeds into the Flutter workflow for packaging - which is more established, and has greater resource to combat the complexities of any Apple/platform ecosystem requirements.

Thanks in advance if you made it all the way through.

[SamYuan1990]

https://samyuan1990.github.io/i18n-agent-action/blog/flet070/

here is my steps and feed backs.
the new impls of file_pick looks good on mac x86 thanks! @ndonkoHenri