mobile-forge or/and chaquopy?

[FeodorFitsner]

Thank you for pushing the whole "Python for mobile" thing forward! (I saw both PEP 730 and 738 were accepted which is great news for community!)

To run Python backend in Flet apps we currently use Kivy. The major pain of running Python on mobile is "native" (non-pure Python) modules. A "recipe" should be made to build native module for iOS or Android.

We are looking for long-term Python solution for Flet and ready to invest efforts into adding/updating recipes and improving packaging process, so I'm studying Kivy alternatives. I've recently found this repo and it's fresh and simple :). It looks like it's mostly for iOS, but it mentions "it could be used to build packages for Android too". Also, there is Chaquopy which has its own packaging.

I'm wondering what's relation between this repo and Chaquopy project, what are you going to evolve going forward, what would you recommend for use to others? Could you please elaborate?

Thank you!

[freakboy3742]

The good news is that BeeWare and Chaquopy are very closely aligned. BeeWare's Android support is entirely built on Chaquopy's tooling, and the founder and maintainer of Chaquopy (@mhsmith) is also a member of the BeeWare project. He and I are both employed full time by Anaconda, with improving mobile support for Python being one of our main responsibilities.

Chaquopy has supported binary wheel packaging for much longer than iOS has; as a result, it has recipes and support for a lot more binary packages. This project was developed to provide the same capability for iOS, with the goal of reconciling Android and iOS package building being a secondary goal. An initial attempt tried to manage iOS packaging as patches against the Chaquopy tools; however, there were enough differences between the two platforms that upstreaming or maintaining a fork was more effort than it was worth.

This project was a clean-room implementation of package building that was able to leverage the lessons learned by Chaquopy, and factor out the details that were known to be different. As a result, it was able to lean more on Python patching build system tooling like crossenv, rather than maintaining "in house" build system patches.

Once the PEP 730 and 738 work is completed, we expect to be looking into the broader Python packaging ecosystem. We haven't fully worked out how we're going to tackle that problem; it might involve merging Chaquopy's Android builds into this project, or we might skip that step, work out what patches need to be passed upstream to crossenv, cibuildwheel et al, and use those changes to incrementally simplify the work being done by mobile forge and Chaoquopy's tooling.

The ultimate goal is that this project (and Chaquopy's equivalent) won't be needed at all. This project only exists because there isn't any capacity to upload binary packages for iOS and Android to PyPI. It's a stop-gap measure so that there is any source of binary wheels for mobile platforms. Eventually, the hope is that the community can take on the packaging task, with iOS and Android being just another build in the CI matrix. That will obviously take a while; in the meantime, we'll publish unofficial binary wheels for high-profile packages so that momentum for the platform as a whole can grow.

If this is an area where you've got an interest because of Flet, we're definitely open to contributions and collaboration. For that matter, we're eager to collaborate with the Kivy folk as well. There's absolutely no reason that 3 teams should be independently maintaining patches and iOS and Android build recipes; once CPython has official support for these platforms, we should have a stable platform that would allow us to share binary artefacts between projects.

For what it's worth, we're also open to making modifications to make Briefcase support Flet natively. Briefcase is a BeeWare project, but it's deliberately not BeeWare-specific - we have builtin support for a couple of other non-BeeWare GUI frameworks, and we'd like to add others if possible. If we can add Flet to that list, all the better.

[FeodorFitsner]

Hi Russell,

Great to meet you and thanks for getting back to me so fast!

I see now - provided details give enough food for my brain to process :)

Currently, we see greater demand for Android, so, perhaps, I'm going to start with learning Chaquopy internals/build system. Then I will look into mobile-forge and Briefcase. We have our own mechanism for packaging user app and its dependencies - would be interesting to see if there is an overlap with Briefcase.

Re: hosting iOS and Android wheels - I was thinking about making an external self-hosted registry for that (thankfully PyPI protocol is simple) and doing CI jobs building/testing/publishing all recipes there. I see Chaquopy has that already, but we need that for iOS packages as well.

Also, I'm going to look into Pydantic 2.0 which is built in Rust. Many packages depend on it.

Btw, we are going to PyCon US this year - it will be great to connect with you guys there for the chat :)

[freakboy3742]

Re: hosting iOS and Android wheels - I was thinking about making an external self-hosted registry for that (thankfully PyPI protocol is simple) and doing CI jobs building/testing/publishing all recipes there. I see Chaquopy has that already, but we need that for iOS packages as well.

FWIW: BeeWare maintains an equivalent PyPI-compatible repository for iOS.

Also, I'm going to look into Pydantic 2.0 which is built in Rust. Many packages depend on it.

I haven't looked at Pydantic specifically, but I've got a fork of setuptools-rust; that package is able to successfully build crytography, but hits a problem at runtime loading one of the internal libraries. I haven't dug into that in depth, though. That's one of the "address the broader ecosystem issues" that is on the list for later this year.

Btw, we are going to PyCon US this year - it will be great to connect with you guys there for the chat :)

Awesome - see you there!

[FeodorFitsner]

FWIW: BeeWare maintains an equivalent PyPI-compatible repository for iOS.

Great! What's GitHub repo it's built from? Is there a CI job for that?

Re: setuptools-rust - could you please point me to sources/docs to see how it should be used to built a binary wheel for iOS?

I would probably have more questions while I'm learning the process. If it's more convenient I can continue on Discord or create a new specific issue here. Thank you!

[freakboy3742]

It's built from this repo. It's the artefacts from mobile-forge, plus the artefacts from the historical approach that mobile-forge replaced (ios_12_0.whl files are the old approach; ios_12_0_iphonesimulator_arm64.whl, ios_12_0_iphonesimulator_x86_64.whl, and ios_12_0_iphoneos_arm64.whl files are the mobile-forge-produced wheels).

Unfortunately, there's no CI process at present; it's all manual builds and publication at present. However, you should be able to reproduce the builds locally with the instructions in the README.

As for setuptools-rust - the PR adding cryptography support shows how you can use that repo in practice to build a wheel that includes rust - with the caveat that the resulting wheel fails runtime tests at present because of an issue with loading a binary at runtime. I haven't got to the bottom of that problem yet.

As for asking questions - ask away! I lurk in the BeeWare Discord most of the day; or if you prefer forum-style, feel free to open a thread here for any questions you have. It's probably best to stick to "one question/theme per thread", to make the details easier for others to follow - but that's just a general guide.