Application Template Generation Seems Frozen for a Large Template git Repository with Slow Internet Connection

[rmartin16]

Describe the bug
Running briefcase create for a large template git repository over a slow connection feels frozen.

For some reason, the briefcase-macOS-app-template repo is 165MB.

For completeness:

~/github/beeware 
❯ du --max-depth 1 -h | grep -i template | sort -h
212K	./Python-Linux-template
236K	./Python-Django-template
240K	./Python-OSX-template
288K	./Python-Windows-template
360K	./briefcase-windows-msi-template
668K	./Python-Android-template
892K	./Python-macOS-template
1.2M	./briefcase-web-static-template
1.4M	./briefcase-linux-flatpak-template
1.4M	./Python-tvOS-template
1.5M	./briefcase-template
1.6M	./podium-template
2.0M	./Python-iOS-template
2.8M	./briefcase-windows-VisualStudio-template
3.0M	./briefcase-linux-appimage-template
3.4M	./briefcase-macOS-Xcode-template
3.5M	./briefcase-windows-app-template
4.0M	./briefcase-iOS-Xcode-template
5.1M	./briefcase-android-gradle-template
165M	./briefcase-macOS-app-template

To Reproduce
Steps to reproduce the behavior:
Run briefcase create macOS app with a slow internet connection….or at least one where GitHub is seemingly throttling the connection.

Expected behavior
Long operations should provide the user with feedback that activity is happening.

Alternatively, ensure the recommended template repos aren't bloated.

Environment:

• Operating System: macOS 12
• Python version: 3.10.7
• Software versions:
  • Briefcase: 0.3.12.dev8+g2435b9b9

[mhsmith]

If most of the size is from the repository history rather the current version, it may also be possible to speed this up using a shallow clone.

[freakboy3742]

That highlights an interesting problem about the "app" repositories (macOS and Windows) - they're going to get big if every time we tag them we get a new binary, and that binary is in source control.

This suggests we should restructure how we're managing those binaries. Maybe it would make sense to include the binary in the support package in some way? After all, the binary is pretty tightly bound to the release of a new support package, and it is a binary artefact.

[freakboy3742]

Thinking about this some more, extracting the binaries as downloadable artefacts should be fairly straightforward. All we really need is a naming convention for where in the S3 bucket the binaries are stored, plus the ability to download and cache those binaries as part of the Briefcase cache.

The hardest part will be purging the GitHub repos so they no longer contain binaries...