Consolidate template repositories
- Dominant language
- Python
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 40
Description
### What is the problem or limitation you are having?
Each cookiecutter template for Briefcase currently has its own repository....but these repositories are remarkably similar and could potentially benefit from consolidating in to a single repository.
https://github.com/beeware/briefcase-android-gradle-template
https://github.com/beeware/briefcase-iOS-Xcode-template
https://github.com/beeware/briefcase-linux-appimage-template
https://github.com/beeware/briefcase-linux-flatpak-template
https://github.com/beeware/briefcase-linux-system-template
https://github.com/beeware/briefcase-macOS-app-template
https://github.com/beeware/briefcase-macOS-Xcode-template
https://github.com/beeware/briefcase-template
https://github.com/beeware/briefcase-web-static-template
https://github.com/beeware/briefcase-windows-app-template
https://github.com/beeware/briefcase-windows-VisualStudio-template
### Describe the solution you'd like
With the release of cookiecutter v2.2.0, the ability to nest multiple templates within a single repository [became](https://github.com/cookiecutter/cookiecutter/pull/1770) a reality. Therefore, we are no longer technically limited to individual repositories.
One motivation for this is maintenance simplification. Twice recently, we had to go through every single template repo and create an identical PR to apply the same update to each one. The similar and shared nature of these repos strongly suggests to me they benefit more from sharing a repo than using their own.
One foreseeable complication is `briefcase-windows-app-template` and `briefcase-macOS-app-template` since these build and contain their stub binary. Given that `briefcase-macOS-app-template` has already [ballooned](https://github.com/beeware/briefcase/issues/933) to 221MB, this binary eventually needs to live outside of the repo; this would provide a convenient opportunity to do this.
I know a desire to ship the templates as [packages](https://github.com/beeware/briefcase/issues/1347#issuecomment-1624496296) has been expressed; although, as also expressed, using a consolidated repo for the templates may make even more sense at that point. ~(I'm not sure I'd like to go so far as putting the templates in the Briefcase repo, though....that's gonna complicate CI quite a bit.)~
### Describe alternatives you've considered
Status quo.
### Additional context
I created this meta-issue to formalize this discussion and ideally create a rough sketch/design of the needed work. Before that, though, I'd like to capture the constraints and considerations for this move.....so, please comment them if you've got em.
Contributor guide
Research direction
Review the listed Briefcase template repositories and the Cookiecutter 2.2.0 nested-template change first. Done means producing an agreed design and migration plan that captures the consolidation constraints, including the Windows and macOS stub binaries and how templates would be packaged or hosted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100