-
-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow third-party packages to supplement Briefcase configuration #1879
Comments
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 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. |
Related: beeware/toga#1020 (comment) |
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
andandroid_manifest_extra_content
in theirpyproject.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
The text was updated successfully, but these errors were encountered: