-
-
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 configuration of custom build params for macos Xcode builds in pyproject.toml #1861
Comments
There's precedent for this sort of thing in the Android configuration - there's a bunch of configuration points that allow for injection of raw configuration items into the Adding more "feature specific" extensions (like "show in dock") depends on being able to expose those in a meaningful cross-platform way. We're unlikely to add a setting to turn on a specific Xcode setting unless there's a reasonable interpretation of that setting for other platforms. |
maybe just check for any collisions between the user's configured
i agree it's not a good idea to do that. IMHO the raw i mean hell just look at Xcode itself - when you add params to |
Except that the values you're describing aren't just "values for your Info.plist". The To support this, I suspect we would need to define a Jinja template field that can parse an Xcode settings block, do a dictionary merge with user-provided values, then output the merged settings. I also want to point out (again) that if your goal is to add
to your app's configuration in the macOS section, these values will be injected into the generated app's Info.plist. This works for both the app and Xcode templates. That doesn't remove the need for this feature, but it does remove one use case for it. |
IMHO a reasonable solution would be to quote "with great power comes great responsibility" in the docs for such a feature and call it a day.
yeah i caught that the first time so thanks for pointing it out - i think it does at least partially solve my Xcode build configuration situation. |
just went back over it and the only customization i had to add to the
|
Are you certain you actually need that setting? The documentation you reference mentions this being used to avoid installing the app into the archive - but Briefcase doesn't use the archive functionality of Xcode. AIUI, you only need to use that functionality if you're planning to distribute through the macOS App Store, which Briefcase doesn't currently support. |
definitely not certain and actually highly skeptical that it's necessary. only reason it's there is because i was following that documentation when i setup my app initially. if it turns out to be unnecessary i'll report back.
curious what you mean by this? is there something about the app bundle created by briefcase that makes it inherently impossible to submit to the app store or is it just that there would need to be some tweaking to get a briefcase app approved? curious bc while i'm initially planning to distribute my app outside the app store i still had at least some vague idea that eventually with some cleanup of entitlements etc. i could offer submit it. |
To the best of my knowledge, there's nothing inherently preventing App Store submission of a Briefcase app. All I'm saying is we (a) don't currently test for macOS App Store-compatible configurations, and (b) don't have a If the process is anything like iOS App Store submission, there's a bunch of stuff that needs to be done around setting signing certificates, and validations that are performed during the archival/submission process. I have no idea if the current Briefcase app will fall foul of these validations - there's an outside chance that the Beyond that, any restrictions are much more likely to be specific to the individual app - e.g., attempting to access file system locations that are prohibited by the App Store Sandbox. We're definitely interested in filling this gap though - "one click" publish-to-App-Store is definitely in Briefcase's long term roadmap, whatever the App Store involved - even if that's just a matter of documenting how to submit to the Mac App Store in the same way as we do for the iOS App Store. |
ok that's what i was expecting - that it wasn't inherently setup for that given the very onerous restrictions around app store apps but that w/some banging around i could hope to sort it out. just doing some experimenting in the last hour or so around sandboxing my briefcase app (bc that's a necessary step) and already ran into some stuff that has to be done via customization briefcase doesn't support that is relevant to this enhancement request... specifically my app tried to read the system-wide the answer was to add an entry to the entitlements but it has to be an array. briefcase docs say only strings and bools are allowed. <key>com.apple.security.temporary-exception.files.absolute-path.read-only</key>
<array>
<string>/private/etc/apache2/mime.types</string>
</array> |
Looking at the implementation, it looks like lists and dictionaries should also be supported (although the ultimate value types in any list/dict will need to be strings and bools). Try it and see if it works; and if it does, a documentation update may be in order. |
i tested it and yeah you're right, lists work fine. here's a documentation change if you want it.
where exactly is that implementation? i tried to check myself in case it was just a documentation error but couldn't find anything - only code i found about entitlements was this line |
also it looks like the |
Dict values are also good; other than that, that change looks good. Feel free to submit a PR (including the changenote) and I'll merge it.
It's being handled by the jinja filter handler for plist values. |
i have been concerned from the get go about this exact entitlement but thankfully it seems like I was able to remove it from my application without anything breaking. I'm not sure if my app ever uses
|
FWIW my app also seems to work fine when i disable the other dangerous entitlement that briefcase turns on by default ( |
Based on your code sample, it looks like you're using PyObjC, which AFAIK doesn't use ctypes; it's directly compiled against the native APIs. That probably means you're safe from ctypes issues. |
ran into some stuff around |
What is the problem or limitation you are having?
I would like a project configuration option in
pyproject.toml
that would allow me to configure arbitrary Xcode build params that briefcase will then inject into the.xcodeproj
template generated bybriefcase create macos Xcode
(or maybebriefcase build macos Xcode
, tbh i'm not sure).for example i modified my templated
project.pbxproj
to add a paramLSUIElement = YES
(which makes the app not appear in the dock - suitable for menu bar apps, console, apps, etc) to thebuildSettings
, which in turn ends up configuringInfo.plist
for the app Xcode ends up building.In
project.pbxproj
it comes out as the lineINFOPLIST_KEY_LSUIElement = YES;
in thebuildSettings
dictionary:Describe the solution you'd like
There's a few possibilities.
LSUIElement
it might make sense to have a full blown "human legible"pyproject.toml
configuration option. Something likeapp_is_ui_element_only = true
orshow_in_dock = false
or whatever; I have no great ideas or strong feelings on the subject.There are of course tons of Xcode configuration options though and manually implementing them all as
pyproject.toml
options seems kind of like a Dark Path that could lead to a lot of unnecessary maintenance (x100 because Apple has a bad habit of silently deprecating or outright disabling things like Xcode environment variables and build params), so I was thinking that just an array named something likexcodeproject_build_settings
inpyproject.toml
with the raw key/value pair Xcode wants would be sufficient to cover everyone's needs in all cases without being all that difficult to use for someone sophisticated enough to be bundling a briefcase app.So it could be something like this in
pyproject.toml
instead if I wanted to injectLSUIElement
andLSBackgroundOnly
asxcodebuild
configurations:You could allow
True
instead ofYES
though I think being "closer to the metal" of Xcode's project file format will make briefcase developers' lives significantly easier in terms of template maintenance down the line.Describe alternatives you've considered
As described in #1859 currently am just manually making these modifications to the
xcodeproj
files and keeping them in source control even though these files exist in thebuild/
directory hierarchy which presumably should need to be kept in version control and should be able to be recreated bybriefcase create
orbriefcase build
.Additional context
There's some backstory on how I am using briefcase to build a bundle I later embed into another app on #1859.
The text was updated successfully, but these errors were encountered: