freakboy3742
commented
1 month ago Thanks for the suggestion. You're correct that packaging apps can have some limitations when you have extremely large bundles - macOS DMGs max out at ~1GB, Google Play store effectively limits Android binaries to 512MB; and MSI has both a 2GB file size limit and a 65k file count limit (see #646).
The WIX configuration files that are currently being generated are generated by template - they're incorporated in the briefcase-windows-app-template and briefcase-window-visualstudio-template (those two are the same file; but there's 2 templates because of difference in how the binary is generated). If you wanted to make any change to the WIX configuration that is used, PRs against those templates is where you'd start.
However, I'm unable to make any recommendations about what would be put in those templates. WIX configuration is... a bit of a mystery; the tool itself is badly documented, and the syntax is extremely complex. The idea you're suggesting - installing a file by downloading as part of the installer... I have no idea if that's even possible.
If it is - then I imagine it would need to be integrated as part of a larger feature in Briefcase itself - i.e., a whole new configuration setting describing a feature of an app that will be downloaded at time of installation. The biggest problem will be that this feature definitely isn't supported by macOS app or DMG installation, Linux Flatpak, iPhone installation, or Android installation processes. It might be possible to integrate into a macOS PKG installer, maybe even an Linux system package; but that's a very narrow subset of packaging options. Briefcase is, ultimately a cross-platform tool, and unless an idea has widespread implementation support, it's difficult to see how it could be added as a Briefcase feature.
My immediate impression, however, is that the best way to handle this isn't to do it in Briefcase, but in the app itself. It's not uncommon for apps to have "first run" behavior that is executed in an app; download a large data file would seem to be fit into that sort of task. This puts the logic entirely in the hands of the app, which can then manage downloads, resumed downloads, progress display, or whatever else is required.
I'll keep this ticket open for now in case someone has any other ideas; but honestly, I suspect this will end up being closed as "not possible".
What is the problem or limitation you are having?
Hello, I have encountered an issue while using the Briefcase package to create MSI installers for applications that include large files, particularly due to dependencies like Torch with CUDA. It appears that Briefcase may have limitations in handling files above a certain size, leading to installation failures.
Describe the solution you'd like
I've read that Briefcase may have limitations with handling files above a certain size when creating MSI installers. I'm particularly interested in modifying the WiX source (.wxs) file to incorporate resuming logic for large file downloads and integrating this with the Briefcase packaging process.
Could you kindly provide guidance on the following:
Modifying the WiX Source (.wxs) File: How can I modify the WiX source file to add resuming logic for large file downloads? For example, how would I customize the WiX component to handle the download and integration of large dependencies like
torch==2.0.0 --extra-index-url https://download.pytorch.org/whl/cu118during the installation process?Describe alternatives you've considered
Integrating Modified WiX Files with Briefcase: Once the WiX source file is modified to include resuming logic, how can I integrate these changes into the Briefcase packaging process? Are there specific steps or configurations within Briefcase that enable the use of custom WiX source files?
I believe implementing resuming logic for large file downloads would greatly enhance the usability of Briefcase for packaging applications with sizable dependencies.
Thank you for your time and assistance.
Additional context
wunjo.wxs.txt