beeware
Provide the option to use uv instead of pip for creating environments and installation
What is the problem or limitation you are having?
uv is an alternative to pip and venv, with the advantage that it is especially fast at creating environments and installing packages. It should be possible to opt into the use of uv instead of pip.
Describe the solution you'd like
It should be possible to configure Briefcase to use uv as the environment management tool. This could be a per-project setting (configured in the wizard); or it could be setting that is configured on a per user basis that a project might choose to override.
Describe alternatives you've considered
Do nothing. pip and venv are perfectly viable solutions that work out of the box.
Additional context
See also #596 - conda is another alternative to uv for environment creation.
Using uv for iOS and Android could be complicated, as those platforms have limited support for mobile platforms.
The speed of uv could make #1735 a lot more palatable. There's no reason we couldn't implement #1735 using pip and venv, but the user experience of taking 30 seconds to start the app every time would be poor. If uv can reduce that startup time to seconds, there's very little downside to creating a fresh virtual environment for every run.
A fast environment creation also resolves some of the issues with #807. If you can build an environment quickly, then there's no real cost to implying -r on every build, rather than making it a separate step.
That would be an option; however, supporting Conda is going to remain on the cards, so anything we do here will likely involve a pluggable interface. The question then becomes what value we use as a default.
At least in the short term, uv support for iOS and Android is likely to be the constraining factor here. uv does support --platform (or an analog - IIRC the spelling is different) - but unless we can install requirements for iOS and Android and/or create an "iOS/Android environment", making uv the default isn't a viable option.
I'd like to start the work on this as part of the EuroPython 2025 Sprints :)
At least in the short term, uv support for iOS and Android is likely to be the constraining factor here.
uv now supports iOS and Android since v0.8.16.
uv does support --platform (or an analog - IIRC the spelling is different)
For reference: pip uses --platform. There you have to specify the platform tag (e.g. android_21_arm64_v8a, ios_13_0_arm64_iphoneos, ios_13_0_x86_64_iphonesimulator). For example you can install an package to some folder with this:
pip install pybase64 --target some_folder --platform ios_13_0_arm64_iphoneos --no-deps
In contrast to this uv uses --python-platform. Not only the spelling is different but also the usage. With uv you have to specify the "target triple" (e.g. aarch64-linux-android, arm64-apple-ios, x86_64-apple-ios-simulator). When targeting a specific minimum iOS version or minimum Android API level you have to specify this via the environment variables IPHONEOS_DEPLOYMENT_TARGET or ANDROID_API_LEVEL. So the same example with uv would look like:
$env:IPHONEOS_DEPLOYMENT_TARGET="13.0"
uv pip install pybase64 --target some_folder --python-platform arm64-apple-ios --no-deps
Thanks for those details.
It's also worth noting that the existing pip- based support might be worth re-working slightly. Using --platform is a little fragile, as dependency resolution isn't transitive without the PYTHONPATH patch that is also used for iOS.
A better approach would be to leverage the work in #2420, and create a full virtual environment in which apps install their dependencies; and then use xvenv (part of xbuild) to convert the iOS environment into a full cross-platform environment, and install into that environment.
In that world, "create a virtual environment" is a feature that can be implemented with venv, or with uv, or with conda; and the cross-platform support is something that is then baked into how that platform handles adding dependencies.