thrift

[Nwokike]

Hello Flet team!

I need thrift for binary protocol support in mobile Flet apps. Because it contains compiled C++ extensions and has no pre-compiled Android/iOS wheels on PyPI, flet build apk fails with a missing wheel error.

Package Details:

• Name: thrift
• PyPI: https://pypi.org/project/thrift/
• Use Case: Apache Thrift runtime library for Python.

Could we get thrift added to the mobile forge (pypi.flet.dev)?

Thank you!

[Arthur031221]

Try Flet's source-package option for thrift:

flet build apk --source-packages thrift

Or set source_packages = ["thrift"] under [tool.flet] in pyproject.toml. Flet's mobile packaging normally accepts binary wheels only; this option permits the named source distribution. Apache Thrift 0.25.0 can fall back to a pure Python wheel if its optional C++ extension cannot compile. I built that wheel with the compiler deliberately disabled and checked a binary-protocol round trip:

$ CC=/bin/false python3 -m pip wheel --no-binary thrift --no-deps --no-build-isolation -q --wheel-dir .tmp/galaxy-thrift-wheel thrift==0.25.0
$ ls .tmp/galaxy-thrift-wheel/*.whl
.tmp/galaxy-thrift-wheel/thrift-0.25.0-py3-none-any.whl
$ PYTHONPATH=.tmp/galaxy-thrift-import python3 .tmp/galaxy-thrift-import/thrift_roundtrip.py
hello 42

The round trip wrote a string and integer with TBinaryProtocol and read them back. This tests the Python fallback, not an APK build. If your app needs the native extension specifically, a compatible mobile wheel would still be needed; for the Python binary protocol, try the source-package setting first.

[ndonkoHenri]

Thanks for digging into this, @Arthur031221. thrift's pure-Python fallback is real, and you're right that the binary protocol doesn't need the C++ extension. It just doesn't kick in under flet build.

With source_packages = ["thrift"], pip builds the sdist on the build machine, in an isolated build environment that doesn't see Flet's mobile platform settings. The machine's compiler works, so the "optional" fastbinary extension compiles successfully for the computer (a macOS binary on a Mac), and the fallback never fires because nothing failed. pip then installs that host-built wheel into the Android/iOS site-packages without checking its platform tag. The APK ends up carrying a macOS Mach-O under lib/<abi>/, and the iOS app gets a broken framework stub. (CC=/bin/false with --no-build-isolation sidesteps both, which is why your desktop test produced a pure wheel; on macOS CC alone wasn't even enough, it took CXX=false too.)

The app still runs, because the import fails on device and thrift drops to pure Python. But the *Accelerated protocol classes retry the failed load every time one is created, and on an iOS simulator that made them 12–23x slower than the plain TBinaryProtocol.

Now that thrift is on pypi.flet.dev with the native codec built for Android and iOS, the simplest path is to add thrift to dependencies and drop source_packages for it; leaving it in still forces the source build. Details are in the recipe README.

[ndonkoHenri]

thrift is now supported on Android and iOS: https://pypi.flet.dev/thrift/

• Docs
• Examples

[Nwokike]

Thanks @ndonkoHenri @Arthur031221