Back port from flet-dev/mobile-forge

[mingchen]

What is the problem or limitation you are having?

Looks like there is fork https://github.com/flet-dev/mobile-forge added more recipes with newer version. e.g. their cryptography even support the latest release https://github.com/flet-dev/mobile-forge/blob/python3.12/recipes/cryptography/meta.yaml

Is there any plan to back port some code to support more recipes like pynacl libsodium etc. ?

Describe the solution you'd like

Port recipes from flet-dev/mobile-forge.

Describe alternatives you've considered

NA

Additional context

I tried to install some package, and it depends on pynacl, then I found flet-dev/mobile-forge.

[freakboy3742]

I'd be happy to incorporate recipes and updates from the flet fork. I wasn't aware @FeodorFitsner had chosen to fork this repo and maintain his own recipe set, rather than submit pull requests to this repo - and I was a little surprised to find out. We met at PyCon US last year, and to the best of my knowledge, I haven't rejected a pull request adding a recipe or a modification to mobile-forge required to support a recipe. He's certainly not required to submit his work as PRs, but I'm not aware of any reason why duplicating effort would be preferable to collaborating.

The Cryptography recipe in particular is very interesting to me, as this suggests he's (a) sorted out Rust/Maturin builds, and (b) resolved the one issue I was aware of with Cryptography in particular, involving loading OpenSSL binaries at runtime.

With that said - my focus hasn't been on mobile-forge lately, because I'm trying to get the changes into the broader Python packaging ecosystem so that Mobile Forge isn't required at all, and iOS/Android wheels can be maintained by each project. PyPI can now host iOS and Android wheels, and I've got initial support into cibuildwheel; I'm working on improvements to that support at present. We've also started initial work on adding Android support to cibuildwheel.

As a result, I'm unlikely to go through the exercise myself of generating PRs to this repo based on the work in the flet fork - but if someone wants to submit PRs, I'm happy to review them, potentially merge them, and publish any resulting wheels on the BeeWare wheel repo.

[FeodorFitsner]

Of course, I've forked the repo to contribute to the parent mobile-forge project. Just wanted to add this and that, here and there, and it went too far :) I'd love to integrate my changes back to upstream to have a single source of truth!

Love the idea of mobile-forge, crossenv and the general implementation of Python runtime and binary packages for iOS. It worked really well since we switched from Kivy and we have successful publishings to App Store!

There are a few things that need to be discussed/solved to push Flet changes back:

1. Android. Flet's fork of mobile-forge was modified to build both iOS and Android packages. Beeware uses Chaquopy for Android, but Flet uses Flutter + our own plugin for Android, so we need Android builds not tight to Chaquopy. And most importantly, we need a 99.99% parity between iOS and Android packages, so developers can painlessly publish to both Google Play and App Store with a "single click".
2. CI. Flet's fork uses CI (AppVeyor) for building and publishing packages. I don't mind switching to GitHub Actions (but not sure about workers availability). Testing would be a huge plus too!
3. Feed. We publish packages to Gemfury repository which is free for OSS and which we control.

Let me know what you think.

I'm going to PyCon US - let's meet there and discuss everything in person! :)

[freakboy3742]

Let me know what you think.

So - my hope is that in a couple of months, Mobile-forge is no longer needed at all. It was a necessary stop-gap measure, and a useful testbed for experimenting with build systems - but we're very close to the Python ecosystem being able to take responsibility for these wheels themselves:

• You can now upload iOS and Android wheels to PyPI. pyspamsum is our proof of concept that this works (that's a package that I maintain, so I can adopt pre-release CI tooling if I need to)

• cibuildwheel has already merged Add support for building iOS wheels. pypa/cibuildwheel#2286, and Add support for building Android wheels pypa/cibuildwheel#2349 is currently in progress. This means that the default tooling for building and testing binary wheels in CI for release purposes is almost in a position to support iOS out of the box.

• I have patches in flight for meson and meson-python to resolve some problems with building binaries (I see you've also submitted a PR to meson recently, but I'm fairly certainly I've found a bug - or at least an unintended consequence - in the code that was merged).

• I have PRs ready to push upstream to Pillow and lru-dict; and I'm in the process of developing a patch for numpy. I've got Numpy building wheels, but not currently passing its own test suite.

In short, we're very close to "submit patches to the upstream repo" being the solution for binary wheels, rather than needing to maintain a third-party repo. The only role mobile-forge would have in that world would be for projects that don't want to add iOS/Android CI patches for some reason - in which case, it's more of a case of maintaining the PR that could be merged upstream, running CI ourselves, and publishing the results somewhere.

I'm going to PyCon US - let's meet there and discuss everything in person! :)

Indeed - I'll be at the Anaconda booth (No BeeWare booth this year, unfortunately); I'm hoping to get an open space or two going as well.