Allow third-party packages to supplement Briefcase configuration

rmartin16 commented 2 weeks ago

What is the problem or limitation you are having?

If we consider a third-party package like bleekWare, it requires users to manually specify specific content in to build_gradle_extra_content and android_manifest_extra_content in their pyproject.toml.

Describe the solution you'd like

Users do not need to manually specify this configuration and Briefcase derives it from the presence of the package.

From a user's perspective, they've already indicated they want to use the package by including it in requires; so, taking the next step of automatically modifying the build process for that package seems at least logical if not reasonable.

Implementation may be complicated, though, in the event of conflicts between existing configuration in a user's project and what a required package wants to do.

Describe alternatives you've considered

Such packages could also publish a related template for users to use that already includes the necessary updates. This seems particularly arduous for everyone involved. And doesn't scale well back trying to use a single package trying to do this in a project.

Additional context

No response

freakboy3742 commented 2 weeks ago

Yet another option - one that Toga is already using for the web backend in an ad hoc fashion - is to include a known data/metadata file that includes this extra information. When you install packages for the web backend, Briefcase currently interrogates the data folder of the package looking for css files, and incorporates them as part of the build. It doesn't seem like a big stretch to extend this to an "android config.xml" (or something similar) that is picked up as part of the Android build process.

The big complication is resolving conflicts with these additions. If I've got one package that declares that Bluetooth permissions must be turned on, but a second that declares that Bluetooth permissions must be turned off - how do I resolve that discrepancy? How do I even detect that this discrepancy exists? The naïve approach would be to just concatenate the lot of them... but that's not going to provide a very observable experience, or a very debuggable one either.

Another complication is where we get access to this extra information. The current workflow creates the template, then downloads the packages. Any metadata tied to the package is therefore becoming available after the template has been rolled out. This means we either need to find a solution for #472, or we need to download packages into a temporary location before they are installed. It's doubly complicated on Android, because Briefcase doesn't download the packages - it's managed by Chaquopy, and all Briefcase does is generate a requirements.txt.

mhsmith commented 1 week ago

beeware / briefcase