You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/how-to/contribute/how/write-code.md
+81Lines changed: 81 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,87 @@ To begin working on code, ensure you have a [development environment](dev-enviro
8
8
9
9
{% endblock %}
10
10
11
+
{% block testing_additional %}
12
+
13
+
### Changing Briefcase templates
14
+
15
+
Briefcase uses templates at runtime to generate the files and project structure for applications. When a contributor runs commands such as `briefcase new` or `briefcase create`, Briefcase selects and renders one or more templates to produce platform-specific project scaffolding.
16
+
17
+
These templates are maintained separately from Briefcase's core code, which allows template development and testing to evolve independently of Briefcase releases.
18
+
19
+
Broadly, Briefcase works with two categories of templates:
20
+
21
+
***Wizard templates**
22
+
These templates are used during `briefcase new` to generate the initial project layout, including files such as `pyproject.toml`, application metadata, and basic source structure.
23
+
24
+
***Platform-specific templates**
25
+
These templates are used during `briefcase create` and later stages to generate platform-dependent project files (for example, to produce a macOS app or iOS XCode project). Each platform has its own template repository that defines how the application is structured and built on that platform.
26
+
27
+
When contributing changes to templates, you need to be able to test those changes locally. Briefcase has features to make this testing possible.
28
+
29
+
#### Testing wizard template changes
30
+
31
+
Wizard templates are used when creating a new project with `briefcase new`. Briefcase allows a user to specify a custom wizard template repository and branch when creating a new project. This makes it possible to test template changes without modifying Briefcase's core code.
32
+
33
+
To test a modified wizard template:
34
+
35
+
1. Fork and clone the [wizard template repository](https://github.com/beeware/briefcase-template) you are working on.
36
+
2. Make your changes in a local branch.
37
+
3. Run `briefcase new`, specifying the custom template repository and branch:
38
+
39
+
```bash
40
+
briefcase new --template ../../../path/to/briefcase-template
41
+
```
42
+
43
+
Alternatively, you can push your changes to GitHub, and then point Briefcase at the GitHub repository and branch for your template fork:
44
+
45
+
```bash
46
+
briefcase new --template "https://github.com/<your-github-username>/briefcase-template" --template-branch my-template-changes
47
+
```
48
+
49
+
#### Testing platform template changes
50
+
51
+
Platform-specific templates are used when deploying a project to a specific platform. This will usually happen when you invoke `briefcase create`, but it can also happen as a result of calling `briefcase build`, `briefcase run`, or `briefcase package`if`briefcase create` hasn't been invoked. These templates define how an application is structured, configured, and built for a specific platform.
52
+
53
+
Briefcase supports using a local copy of a template using the [`template`][] and [`template_branch`][] options. To test a modified platform template:
54
+
55
+
1. Fork and clone the platform template repository you are working on (e.g., [this template](https://github.com/beeware/briefcase-macOS-app-template) for macOS apps).
56
+
2. Make your changes in a local branch.
57
+
3. Open the project’s `pyproject.toml` file.
58
+
4. In the platform-specific configuration section, set the template to use when creating the app. During initial development, it will be easiest to point at a local checkout of the template:
#### Template changes that require Briefcase changes
74
+
75
+
In some cases, changes to a template may depend on corresponding changes in Briefcase itself. For example, if you add a new context variable, or modify the behavior of Briefcase to change how a template variable is constructed, you may require both a Briefcase *and* template change.
76
+
77
+
This situation then causes problems during testing, because Briefcase's tests won't pass with an old template, and tests for the template won't pass with an old version of Briefcase.
78
+
79
+
To work around this situation, pull requests on Briefcase's template repositories support a syntax for pointing at a specific version of Briefcase. Once you've made changes locally to both Briefcase and the affected template, and you're satisfied that they work, push the changes for both to Briefcase, and open a pull request on each repository.
80
+
81
+
In the PR description for *Briefcase*, provide details of the template branch that is required for testing. If the template changes are needed for the Briefcase tests to pass, flag this fact in the PR description; this lets reviewers know that the process of merging the PR will be more complicated.
82
+
83
+
In the PR description for the *template*, include the following two lines:
This directs the template tests to use a branch of Briefcase for testing. This should allow the template tests to pass. The person reviewing your PR will review both the Briefcase *and* template changes together. If approved, the template change will be merged, and tests on Briefcase will then be re-run. This provides a final confirmation that the template and Briefcase are compatible.
89
+
90
+
{% endblock %}
91
+
11
92
{% block end_matter %}
12
93
13
94
Once you have everything working, you can [submit a pull request](submit-pr.md) with your changes.
0 commit comments