forked from pypa/sampleproject
-
Notifications
You must be signed in to change notification settings - Fork 3
/
copier.yaml
188 lines (146 loc) · 7.22 KB
/
copier.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
_subdirectory: template
project_name:
type: str
help: What is the name of your project?
placeholder: Sample Project
expected: Title case string, can contain spaces
explanation: |
The project name will be used to propose a suitable package name and [Remote Url][remote-url].
It is also repeated in multiple places (Python package configuration, documentation, etc.).
package_name:
type: str
help: What is the name of your Python package?
default: "{{ project_name|lower|replace(' ', '_')|replace('-', '_') }}"
expected: Lowercase string, can contain underscores
explanation: |
This is the name of your Python package. As such, it will be used as the name of the directory containing your code.
All imports of your package start with this name.
Example: If you choose `sample_project` as your package name, your code files would be created in
```
./
├── src
│ └── sample_project
│ ├── __init__.py
│ ├── __main__.py
│ └── some_module.py
├── pyproject.toml
└── ...
```
and your imports would look like this:
```python
from sample_project import some_module
```
You might want to consult [PEP 423 – Naming conventions and recipes related to packaging](https://peps.python.org/pep-0423/)
for guidance on Python package name conventions.
The cli command included with this template will be named after your package, only with dashes instead of underscores.
Following the example above, your cli would then be available as
```console
$ sample-project --help
```
If you ever want to publish your Python package to [PyPI](https://pypi.org), the package name has to be unique to be accepted there.
Finally, the package name is repeated across multiple configuration and documentation files.
precommit:
type: bool
default: true
help: Use pre-commit to run checks on each commit?
explanation: |
[pre-commit](../reference/tooling/pre-commit.md) is a tool that makes configuring [git hooks][git-hooks] a lot easier.
This template uses pre-commit hooks to ensure, all changes match the expected formatting and style.
Additionally, running linters at this stage can prevent committing something that contains obvious issues.
Most formatters and some linters are able to fix issues automatically.
So you can simply review the changes those tools made, stage them and commit again.
bumpversion:
type: bool
default: false
help: Use bumpversion to manage semantic version across multiple files?
explanation: |
If you want to version your project, [bumpversion][] provides an easy way to increase version numbers across multiple files.
It integrates with git and helps with your release workflow by automating version bump, commit and tag creation.
Used correctly, releasing a new version of your project can be done with a single command.
It also helps to follow [semantic versioning][semantic-versioning] guidelines when increasing your version numbers.
docs:
type: str
choices:
Material for MkDocs: mkdocs
Sphinx: sphinx
None: none
default: "mkdocs"
help: Which documentation tool do you want to use?
explanation: |
[Documentation][documentation] is an important part of any project.
So far, this template supports two documentation tools: [MkDocs][mkdocs] and [Sphinx][sphinx].
[MkDocs][mkdocs] is a great documentation tool built around [Markdown][markdown].
It is easy to use and produces a great looking documentation website with minimal overhead and configuration.
[Sphinx][sphinx] is a powerful tool for documentation written in [Markdown][markdown] or [reStructuredText][restructuredtext].
With the [`myst_parser`][myst_parser] it is now (almost) possible to rely on Markdown only.
Choose this if you want to publish your documentation in multiple formats (e.g. PDF, HTML, ePub, ...).
If you are not sure which one to use, simply go with the default 😉.
docs_template:
type: str
choices:
Fraunhofer IIS Sphinx Template: sphinx-fhg-iis
None: none
default: "none"
when: "{{ docs == 'sphinx' }}"
help: Which documentation template do you want to use?
explanation: |
See [Fraunhofer IIS Sphinx Template](https://git01.iis.fhg.de/sch/sphinx_template/).
remote:
choices:
GitHub: github
FHG Gitlab: gitlab-fhg
IIS Gitlab: gitlab-iis
help: Which platform will your project be hosted on?
default: "github"
explanation: |
This template provides a CI configuration for either GitHub (Github Actions) or GitLab (Gitlab CI).
Also, the link to your documentation depends on which remote you choose.
If you want to push your project to multiple remotes, you can add them later.
user_name:
type: str
help: User name (the one you used with your hosted git provider)
explanation: |
This is the user name you are using with the remote provider you provided in the previous question.
Together with [remote][], it will be used to suggest a [remote url][remote-url] for your project.
email_address:
type: str
help: Email address of the author
default: "{{ user_name|lower }}@iis.fhg.de"
explanation: |
This is the email address for the author of the project.
remote_url:
type: str
help: URL of the remote repository
default: git@{% if remote=='github' %}github.com{% elif remote=='gitlab-iis' %}git01.iis.fhg.de{% elif remote=='gitlab-fhg' %}gitlab.cc-asp.fraunhofer.de{% endif %}:{{user_name}}/{{project_name | lower | replace(' ', '-')}}.git
expected: SSH URL to your remote repository
explanation: |
Apart from configuring the git remote for you, the remote URL is required to determine other values, such as
- Links in your README and CHANGELOG files
- Links to your documentation
- Link to your repository from your documentation
- ...
If you did not create your remote repository yet (i.e. new project at GitHub or Gitlab), this might be a good time to do so.
!!! tip "Create empty repository"
Do not initialize your remote project with a LICENSE or README file.
This will let you push your initial commit without merge or rebase.
=== "Gitlab"
*The SSH URL to your Gitlab repository can be found under the `Clone` dropdown (screenshot taken 23.08.23)*{.caption}
=== "GitHub"
*The SSH URL to your GitHub repository can be found under the `<> Code` dropdown menu (screenshot taken 23.08.23)*{.caption}
default_branch:
type: str
default: main
help: Name of the initial git branch that will be created
expected: Lowercase string, can contain dashes
examples: [main, master, dev]
explanation: |
Name of the [initial branch][] of your new project.
This branch traditionally was called `master`, but is more often called `main` now.
[initial branch]: https://git-scm.com/docs/git-init#Documentation/git-init.txt---initial-branchltbranch-namegt
_tasks:
- "rm -rf context"
- "git init --initial-branch={{default_branch}}"
- "git remote add origin {{remote_url}} || true"
- "{% if precommit %}pre-commit install || echo 'Error during installation of pre-commit hooks. Is pre-commit installed?'{% endif %}"