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
This repository is a [template repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template) providing boilerplate for Python library.
10
9
11
10
Developer can start writing code without wasting so much time to set up basic stuffs like CI, lint, etc.
12
11
13
12
## Table of Content
13
+
14
14
-[Usage](#usage)
15
15
-[Installation](#installation)
16
16
-[Install Poetry](#install-poetry)
@@ -26,6 +26,7 @@ Developer can start writing code without wasting so much time to set up basic st
26
26
---
27
27
28
28
## Usage
29
+
29
30
We recommand to use GitHub's `Use this template` button to kick off this template.
30
31
But yet, you can set up copy this template by cloning or downloading this repository.
31
32
@@ -38,15 +39,18 @@ Subsequent Installation step might be helpful.
38
39
## Installation
39
40
40
41
### Install Poetry
42
+
41
43
Please read this [installation guide](https://python-poetry.org/docs/) to install poetry.
42
44
43
45
Then install package dependencies with this command at project root.
44
46
This will resolve package dependencies and install it in poetry managed virtual environment.
47
+
45
48
```
46
-
$ poetry install
49
+
poetry install
47
50
```
48
51
49
52
### (Optional) Install Pyenv
53
+
>
50
54
> pyenv lets you easily switch between multiple versions of Python.
51
55
It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.
52
56
@@ -55,6 +59,7 @@ As quoted [pyenv readme](https://github.com/pyenv/pyenv/blob/master/README.md) d
55
59
### Configuration
56
60
57
61
#### pyproject.toml
62
+
58
63
This file contains build system requirements and information, which are used by poetry to build the package.
59
64
We tried to gather every package related settings as much as possible here.
60
65
Through this design decision, project could remove package dependant configuration files like `.isort.cfg`, `pytest.ini`, etc.
@@ -68,6 +73,7 @@ Through this design decision, project could remove package dependant configurati
68
73
Except **[build-system]**, We suggest you to update every settings above.
69
74
70
75
#### .github/workflows/ci.yml
76
+
71
77
We choose GitHub action as Continuous Integration tool. It contains package-build, unittest, and lint job.
72
78
Each job works concurrently on different virtual machines.
73
79
@@ -78,6 +84,7 @@ Each job works concurrently on different virtual machines.
78
84
Change `python-version` value in this file according to package compatible python versions which configured at `pyproject.toml`.
79
85
80
86
#### tox.ini
87
+
81
88
Tox runs test against packages which built in isolated virtual environment.
82
89
83
90
-**[tox]**: Tox global settings.
@@ -87,19 +94,23 @@ Tox runs test against packages which built in isolated virtual environment.
87
94
According to package's python compatible versions, **[tox.envlist]** and **[gh-actions]** should be defined.
88
95
89
96
#### Source code
97
+
90
98
Make your own named package in src directory.
91
99
92
100
**NOTE**: package setting in `pyproject.toml` should be changed as you set up your own package.
101
+
93
102
```
94
103
packages = [
95
104
{ include = "{your-python-package-name}", from = "src" },
96
105
]
97
106
```
98
107
99
108
#### Test Code
109
+
100
110
Every test code should resides in `tests` package at project root.
101
111
102
112
To test your source code, simply use 'pytest' or 'tox'.
113
+
103
114
```
104
115
# Use pytest
105
116
$ pytest tests/
@@ -111,9 +122,11 @@ $ tox
111
122
---
112
123
113
124
## Architecture
125
+
114
126
Detailed explanation about stacks used in this template is covered in this section.
115
127
116
128
### Project Layout
129
+
117
130
This template repository follows src layout style. As the name suggests, its distinctive feature is subdirectory named `src`.
118
131
Main python packages lives inside `src` directory.
119
132
@@ -123,6 +136,7 @@ Src layout helps to achieve this condition. By separating source code from proje
123
136
This layout is better explained in this [blog post by Ionel Cristian Mărieș](https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure).
124
137
125
138
### Dependency Management & Packaging
139
+
126
140
We use [Poetry](https://github.com/python-poetry/poetry) to control dependencies and build package.
127
141
Advantages of using poetry is well explained in their [README.md](https://github.com/python-poetry/poetry/blob/master/README.md).
128
142
@@ -131,9 +145,11 @@ It frees developer from virtual environment management. But also offers option t
131
145
For more information read this [docs](https://python-poetry.org/docs/managing-environments/)
132
146
133
147
### Continuous Integration
148
+
134
149
Our GitHub action consists of two workflows. one for CI, and one for release draft.
135
150
136
151
`ci.yml` workflow contains three different jobs. Those are package-build, unittest, lint.
152
+
137
153
-**package-build** job is responsible for build package and test it. so it uses tox and can have multiple python versions.
138
154
-**unittest** job is in charge of test on source code, and report test coverage.
139
155
-**lint** job processes every linting stuffs.
@@ -144,27 +160,32 @@ Release draft template can be modified by editing `.github/release-drafter.yml`
144
160
It demonstrates how draft should be presented.
145
161
146
162
### Testing
163
+
147
164
[Pytest](https://github.com/pytest-dev/pytest/) is our main test runner.
148
165
149
166
### Linting
167
+
150
168
Code is double-checked during development process. One at commit phase, and the other at CI process.
151
169
152
170
[pre-commit](https://pre-commit.com/) is help us to check at commit time. By executing installation command `pre-commit install`,
153
171
It automatically adds pre commit hooks. Types of hook are managed using `.pre-commit-config.yaml`.
154
172
155
173
### Coverage
174
+
156
175
Coverage of test functions is one of important metrics which decides code quality.
157
176
`ci.yml` workflow runs unittest and reports coverage report on pull request comment.
158
177
We use [orgoros's github action](https://github.com/orgoro/coverage) as our coverage component of our CI workflow.
0 commit comments