search

beeware / briefcase

Tools to support converting a Python project into a standalone native application.
https://briefcase.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
2.47k stars 350 forks source link

Manage stub binaries as external resources #1849

Closed freakboy3742 closed 3 weeks ago

freakboy3742 commented 1 month ago

The macOS and Windows app templates include a stub binary; however these binaries are currently managed as artefacts in the macOS/Windows app template. As the template is git repository, it contains the full history of all changes to the template; as a result, on first use, the user must download all historical stub binaries as part of the template.

This change modifies the handling of stub binaries so that they are external artefacts, analogous to the support package. They will be stored on S3, same as the support packages, and cached on use; however, as they're managed as external resources, the base template can be made a lot smaller.

This change by itself won't reduce the size of the template checkout, as cookiecutter does a full repo clone. #1855 adds a modification that does a blobless clone, which will reduce the size of the initial repository clone.

This change requires a template update to take full effect; but, conveniently, CI will pass without any changes, because the stub binary that is unpacked from a downloaded archive has the same name as the stub binary that is generated by the current app template, and the current app template doesn't have the marker that indicates a stub needs to be downloaded.

Refs beeware/briefcase-macOS-app-template#58 Refs beeware/briefcase-windows-app-template#51

Fixes #933.

PR Checklist:

mhsmith commented 3 weeks ago

As we discussed yesterday, the way this will work is:

This means that in the app repository, the tag for each build will always be on the commit before that build was adopted, e.g. the tag for build 6 will always be on a commit that says stub_binary_revision = 5.

Also, there's no direct link between the stubs and the source code they were built from. You'd have to work it out by comparing the timestamps of the two repositories.

These could both be fixed if the tags and the actions were moved to the VisualStudio or Xcode repository instead.

freakboy3742 commented 3 weeks ago

These could both be fixed if the tags and the actions were moved to the VisualStudio or Xcode repository instead.

I thought about that; I wasn't sure if it was odd to have something that only the app template uses being controlled by a different repo. However, your point about having a tag on the exact code being used is a good one that I hadn't considered. I'll put up PRs to migrate the binary tagging over to the Xcode/VS template repo.