beeware
Support for Conditional Commands Based on Windows Target in Briefcase Configuration
What is the problem or limitation you are having?
Currently, Briefcase supports conditional configuration for Linux systems based on the target distribution (e.g., [tool.briefcase.app.wunjo.linux.system.debian] or [tool.briefcase.app.wunjo.linux.system.rhel]). However, I tried to implement a similar configuration for Windows with a target like [tool.briefcase.app.wunjo.windows.msi], but it didn’t work as expected. Specifically, I wanted to define custom paths or commands for different Windows formats (e.g., .msi vs. .zip) but was unable to do so.
Describe the solution you'd like
I would like the ability to define platform-specific configurations in a similar way to how it is done for Linux, for example:
[tool.briefcase.app.wunjo.windows.msi]
cleanup_paths = [
"**/app_packages/torch",
"**/app_packages/torchvision",
"**/app_packages/torchaudio"
]
[tool.briefcase.app.wunjo.windows.zip]
sources = [
".portable"
]
This would allow users to tailor the configuration based on the type of Windows package being built (MSI vs. ZIP) and make customizations such as specifying paths, adding or removing files, or defining different build commands.
Describe alternatives you've considered
Currently, there are no alternatives in Briefcase to achieve this level of granularity for Windows targets. I considered manually managing different configurations outside of Briefcase, but that would defeat the purpose of using the tool for automation.
Additional context
This feature would greatly enhance the flexibility of Briefcase for cross-platform development, especially for scenarios where specific commands or paths need to be handled differently based on the target package format on Windows.
Thanks for the suggestion.
I'm not entirely clear I understand the use case you have for this. What sort of content do you want to include in a .msi bundle, but not in .zip (or vice versa)? The suggestion is there's a .portable file you want to include in .zip files - that's not a file I've seen before. Is it something specific to your project? Historically, I've considered the packaging format to be a fairly benign "this is how you get this directory of stuff onto another user's computer", not something that would require different configuration.
However - assuming we did add this - there's some complications. The analogy with Linux isn't entirely accurate; although Linux system packages do allow for a level of differentiation deeper than system, those configurations are mutually exclusive - system.rhel implies producing a RHEL RPM; and you can't produce a RHEL RPM on Debian.
Windows already does allow for format-based configuration splits - the catch is that the "format" is app or VisualStudio. zip and msi are packaging formats, which doesn't have any form of differentiation at present (which is the problem you're hitting).
So - the direct analog with Linux would be [tool.briefcase.app.wunjo.windows.app.msi] - but that then ignores the fact that MSI-specific configuration items could presumably be shared with VisualStudio - so you'd need to duplicate those settings in [tool.briefcase.app.wunjo.windows.VisualStudio.msi], which isn't ideal.
Alternatively, we could possibly allow for [tool.briefcase.app.wunjo.windows.msi] as a configuration layer; but then we have the question of the order of priority of layers. What is the relative evaluation priority of [tool.briefcase.app.wunjo.windows.msi] vs [tool.briefcase.app.wunjo.windows.app]?
From a purely implementation perspective, the easiest solution would be for the order of evaluation to be:
[tool.briefcase.app.wunjo.windows.app][tool.briefcase.app.wunjo.windows.msi][tool.briefcase.app.wunjo.windows.app.msi]
This could be implemented entirely in the Windows backend, as part of a finalize_app_config() definition on the Windows base class (similar to how the Linux formats are handled; noting #2188 as a known bug in that implementation at present); and I guess this could be documented as "packaging formats configuration changes are merged after formats"... so maybe that makes enough sense?
Thanks for your detailed response! Let me clarify the use case and why this would be valuable.
Problem: MSI Size Limitations vs. ZIP Flexibility
The main issue is that MSI has strict size limits (e.g., CAB archives maxing out at 2GB), while ZIP does not. In my project, dependencies like torch, torchvision, and torchaudio push the installer beyond this limit, causing failures. Currently, I manually exclude these files for MSI builds but keep them in the portable (ZIP) version. (This important do after briefcase build pip because of other libraries related to torch and can be third depending library).
A format-specific config (e.g., include_msi/include_zip) would automate this (I also use GitHub Actions CI), avoiding manual edits per build.
The .portable File (Project-Specific Trigger)
This file signals that the app runs in portable mode (ZIP version) and should:
Store cache/data in the program directory (not %APPDATA%).
Skip installer-specific logic (e.g., Program Files registration).
For MSI builds, this file shouldn’t exist, as system-wide installation behaves differently.
Thanks for your option of separating configurations, I'll try it. And I like how sound solution with [tool.briefcase.app.wunjo.windows.app.msi] and [tool.briefcase.app.wunjo.windows.VisualStudio.msi] or [tool.briefcase.app.wunjo.windows.app.zip] because it creates a sense of separation by method build.
The main issue is that MSI has strict size limits (e.g., CAB archives maxing out at 2GB), while ZIP does not.
FYI - this is a known issue (#646), which I believe will be fixed by #1185. Upgrading WIX to a more recent version is on our near term roadmap - definitely in the next 6 months. Of course, if someone wants to beat us to it... 😄
This file signals that the app runs in portable mode (ZIP version) and should:
Ok - that makes sense; it's a niche use case, but I can see how it could be useful.
Thanks for your option of separating configurations, I'll try it. And I like how sound solution with [tool.briefcase.app.wunjo.windows.app.msi] and [tool.briefcase.app.wunjo.windows.VisualStudio.msi] or [tool.briefcase.app.wunjo.windows.app.zip] because it creates a sense of separation by method build.
If you need any pointers on getting starting with a PR implementing this, let us know!