beeware / beeware/briefcase

Consolidate template repositories

Open
#1,523 5 comments 0 reactions 0 assignees View on GitHub
enhancement not quite right
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.