Use isolated virtual environments for app builds.

[freakboy3742]

Part of series of changes extracted from #2917.

Use fully isolated environments for app builds. This ensures that the environment running Briefcase has no influence on how apps are constructed, and allows the installation of requirements to be fully abstracted as an environment behaviour.

Adds tooling to create a virtual environment as part of app creation, and that virtual environment is used to install requirements into the app. The app environment is re-created whenever requirements are installed (or re-installed)

During update, the support package is now installed before installing requirements. This matches the order of the create command.

Moves app verification to before the installation of the support package but after template generation.

As part of this change, install_requirements() and _install_requirements() have been required so that the latter just does the requirements install; this allows platforms like iOS and macOS to override that to do 2-pass and/or merged installs.

PR Checklist:

• I will abide by the BeeWare Code of Conduct
• I have read and have followed the CONTRIBUTING.md file
• This PR was generated or assisted using an AI tool

[mhsmith]

This ensures that the environment running Briefcase has no influence on how apps are constructed

What kinds of influence have you seen?

The app environment is re-created whenever requirements are installed (or re-installed)

This causes a significant slowdown in reinstalling requirements, for example briefcase update -r for a simple app has gone from 3 seconds to 6 on my laptop. Presumably the same thing has already happened to briefcase dev -r.

The vast majority of this is from installing pip into the new environment, and then updating it to its current version. However, there's a way to avoid this:

• Pass the --without-pip argument to python -m venv.
• Use the copy of pip from Briefcase's own virtual environment, passing the --python argument to point at the app's virtual environment. This will cause pip to re-execute itself within that environment, which I believe should give sufficient isolation.

[freakboy3742]

This ensures that the environment running Briefcase has no influence on how apps are constructed

What kinds of influence have you seen?

The main way I see this manifest: If I have a environment with an editable install of Briefcase and Toga installed, and I create an app that lists toga==something (any specific version), pip will raise warnings about incompatible versions of toga (because the environment has a version that isn't compatible with what is being installed).

The app environment is re-created whenever requirements are installed (or re-installed)

This causes a significant slowdown in reinstalling requirements, for example briefcase update -r for a simple app has gone from 3 seconds to 6 on my laptop. Presumably the same thing has already happened to briefcase dev -r.

That's correct. I agree this performance isn't great; but it's also a case where I think correctness trumps performance.

That said - it's also an area where uv helps a lot - environment creation (and thus app creation) is near instantaneous.

The vast majority of this is from installing pip into the new environment, and then updating it to its current version. However, there's a way to avoid this:

• Pass the --without-pip argument to python -m venv.
• Use the copy of pip from Briefcase's own virtual environment, passing the --python argument to point at the app's virtual environment. This will cause pip to re-execute itself within that environment, which I believe should give sufficient isolation.

Interesting... and that has the added benefit that pip won't be in the installed app environment. I'll tinker with this and see if I can make it work.

[freakboy3742]

Interesting... and that has the added benefit that pip won't be in the installed app environment. I'll tinker with this and see if I can make it work.

Well... that was really straightforward, and works incredibly well. The environment creation step is now near-instantaneous, in both dev and create.

[mhsmith]

Suggest changing this example to userequirement_installer_args, and moving it to that option's section, because it doesn't currently have any examples except for those involving path transformation.

[freakboy3742]

Agreed this example needs to be updated; I was planning to tweak these docs as part of the uv update (since that's the point where requires strictly stops being a "you can pass in any installer arg" option.

[mhsmith]

Why require this on Windows? If there's a good reason, then it should be explained in a comment, and a removal change note should be included.

[freakboy3742]

The reason is similar, but not identical to macOS - a combination of security (so app builders aren't running code to do an install), and protection against the lack of a compiler by default on Windows.

I've reworked how this is set up so that "require = True" is the default (migrating the documentation from the macOS version), with Linux getting a specific opt-out.