Open Ruben-Kruepper opened 1 year ago
I'd be happy to contribute but would like to establish a discussion first 😁
Agreed that there is something needed in this space.
As an immediate workaround - the solution is to fork the default Briefcase template and add your Info.plist et al customisations. This isn't a great long term solution as it requires a lot of maintenance on the part of the developer, but it will work.
Although you've framed this in terms of Apple code signing specifically, Briefcase tends not to lean towards platform-specific solutions, unless a specific platform "escape hatch" is needed. For example, Linux packaging needs the ability to define system packages; there's no analog for this on any other platform. Wherever possible, we find a platform-abstracted representation that we can use. Looking at the data in a macOS Info.plist specifically: we have a metadata representation for file format registrations.
In particular, my concern is the overlap of this feature with #547. Permission handling is a feature that will be needed on every platform. Although the specific "spelling" of permission handling is different on every platform, the broad concept is the same - there's a list somewhere that details the permissions that the app requires: "Camera access", "microphone access" and so on. Ideally, we want to be in a situation where a user can flag "My app uses the camera" as a single setting, and the appropriate platform-specific permission will be added to app metadata.
So: In terms of implementing this feature, the first step is discovery - clearly identifying the use cases for the feature to work out what specific features we need to accomodate in Apple, and which of those have analogs on other platforms. Permissions is one; but what others exist? Once we've got an idea of the landscape we need to support, solutions might become more apparent.
While the immediate macOS solution might look like "a setting to specify a custom Info.plist file" (or similar), that solution will (a) only work for macOS (and maybe iOS), (b) requires deep knowledge about how to write an Info.plist file, and (c) won't do anything to address analogous problem on other platforms. It might be a part of where we end up, but I'd prefer not to use that as a starting point for a design.
In terms of permissions, in my ideal world, we'd have:
with analogous mechanisms for other properties that are defined in the macOS/iOS Info.plist.
So - if you're interested in contributing, step 1 is research. Write up a summary of the features we need to support on macOS; if you're comfortable poking around the docs for other platforms (iOS and Android in particular, as they're the platforms with the richest concept of permissions and signing), that will make the process a lot easier. A summary of what other tools (like PyInstaller) do in this space will also be helpful to guide discussions.
What is the problem or limitation you are having?
As far as I can tell, currently there is no way to inject custom
Info.plist
items for MacOS bundles. Also, there is no way to configureEntitlements.plist
before signing or inject aprovisioningprofile
. All of these features seem critical for a good experience on all Mac platforms imho.Describe the solution you'd like
I feel there are two reasonable options here:
info_plist
,entitlements_plist
fields to thepyproject.toml
macOS
section which allow specifying keys similar to the way PyInstaller handles things, as well as aprovisionprofile
which points to a.provisionprofile
which should be embedded in the App.Entitlements.plist
andInfo.plist
part of theresources
directory and use them accordingly. Allow optionally the addition of a.provisionprofile
to theresources
directory, which will be embedded if specified.Describe alternatives you've considered
Both above feel reasonable in the spirit of the design imo.
Additional context
If this is not integrated, the only option is to build (which signs), then modify the bundle in a post-build step, then sign the bundle again (since it's signature just got invalidated).