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: CONTRIBUTING.md
+66-2Lines changed: 66 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,9 @@
1
1
# Contributing Guide
2
2
Hey there, looks like you're interested in contributing to Bpy-Build! To get started, read this guide which has a lot of important information regarding contributions.
3
3
4
+
> [!CAUTION]
5
+
> For those that have contributed to MCprep in the past, note that BpyBuild has stricter contributing requirements in comparison.
6
+
4
7
This guide will assume you already know how to use Git and understand enough Python to know how to use type annotations.
5
8
6
9
# Building Bpy-Build
@@ -17,7 +20,7 @@ The Bpy-Build project does not allow dynamic typing at all, period. The reasons
17
20
- Reliability: Dynamic typing is an extra source of bugs to deal with
18
21
- Cleanliness: Dynamic typing ends up looking extremely ugly
19
22
20
-
All functions must be type annotated. It is possible to add `@typing.no_type_check`above functions that need to call untyped code (which is considered dynamic by Mypy, the type checker used here) to prevent Mypy from throwing errors with untyped functions. However, instances of `@typing.no_type_check` in contributions will cause said contributions to be rejected. Thus, for contributions, we creating wrappers for untyped functions and performing casts.
23
+
All functions must be type annotated. Instances of `@typing.no_type_check`or `# type: ignore` that aren't justified with a comment will cause said contributions to be rejected. Thus, for contributions, we creating wrappers for untyped functions and performing casts.
21
24
22
25
We require every commit pass Mypy checks, which we utilize pre-commit hooks for (see the Pre-Commit Hooks section for more). Alternatively, you can use the following:
23
26
```sh
@@ -26,6 +29,17 @@ just mypy
26
29
# Or if you don't have just installed
27
30
poetry run mypy --pretty bpy_addon_build
28
31
```
32
+
33
+
All commits will be checked for passing tests, and PRs will be rejected if one does not pass the Mypy checks.
34
+
35
+
## Typing
36
+
Although BpyBuild supports Python 3.8, we try to use [PEP 585](https://peps.python.org/pep-0585/) types wherever possible, using `annotations` from the `__futures__` module. This means for the most part, `dict`, `list`, `tuple`, etc. can be used with little issue. That being said, the following has to be kept in mind:
37
+
- These annotations are hackish in the CPython interpreter, so these can't be used for `attrs`/`cattrs` classes, or if `cast` needs to be performed. In those cases, their `typing` counterparts will have to be used
38
+
- New files that use PEP 585 annotations will need to have `from __future__ import annotations` as the first import in the file
39
+
- Although it would be nice, [PEP 604](https://peps.python.org/pep-0604/) syntax for Unions is not an option with `__futures__` in Python 3.8
40
+
41
+
Despite some of the headaches with using annotations from `__futures__`, we encourage their use so that migrating becomes less of a burden in the future.
42
+
29
43
# Formatting
30
44
All commits must be formatted with https://github.com/astral-sh/ruff. We have a pre-commit hook for this (see the Pre-Commit Hooks section).
31
45
@@ -47,7 +61,13 @@ characters long (for reasons related to terminal
47
61
length)
48
62
```
49
63
50
-
For a small commit, like say fixing a syntax error or typo, it may be sufficient to have just a summary, but most commits will need justification. Commits should justify the changes made, not repeat them like a parrot (that's what the 50 character summary and Git diffs are for). Failiure to follow proper commit format may prevent a contribution from being accepted into Bpy-Build, so please follow the format.
64
+
In addition, the 50 character summary at the top must follow the [Conventional Commit Format](https://www.conventionalcommits.org/en/v1.0.0/).
65
+
66
+
Commits that fall under the following **ARE REQUIRED** to give justification:
67
+
-`feat`
68
+
-`refactor`
69
+
70
+
That being said, it's best to give justification for every commit.
51
71
52
72
To make meeting this requirement easier, one can make a `.gitmessage` file somewhere with the following :
This will make all commits use that template and perform verbose commits (where commits are opened as their own file, with saving and closing creating the commit itself).
72
92
93
+
## Commits MUST *fully commit* to a given change
94
+
When a commit is made, the change stated in the commit must be fully committed to. For example, a commit that states `refactor: Use sys.exit method for program exit`**must** implement that change across all files, not just one or two.
95
+
96
+
## Signing Off Commits
97
+
BpyBuild requires signing off of all commits, to certify the origin of the change. When you sign off of a commit in BpyBuild, you certify that the commit was made in line with the Developer's Certificate of Origin:
98
+
99
+
> Developer's Certificate of Origin 1.1
100
+
> By making a contribution to this project, I certify that:
101
+
>
102
+
> a. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or \
103
+
> b. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or \
104
+
> c. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. \
105
+
> d I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
106
+
107
+
If indeed the change was made in line with the Developer's Certificate of Origin, add the following at the end of the commit:
108
+
```
109
+
Signed-off-by: Random J Developer <random@developer.example.org>
110
+
```
111
+
112
+
**This much be your real name and a working email address.**
113
+
114
+
If the change was given to you by someone else, and you have permission to contribute it here, that change must be signed off by the person who gave the change to you, and anyone before that (basically a chain of sign offs). Example:
115
+
```
116
+
<commit message and summery by John Doe, who recieved the change from Jane Doe>
117
+
118
+
Signed-off-by: John Doe <johndoe@email.com>
119
+
Signed-off-by: Jane Doe <janedoe@email.com>
120
+
```
121
+
122
+
If multiple authors were involved in writing the change, then `Co-developed-by` must be present for both you and any other authors involved in the change. As an example with 2 authors:
123
+
```
124
+
<commit message and summery>
125
+
126
+
Co-developed-by: John Doe <johndoe@email.com>
127
+
Signed-off-by: John Doe <johndoe@email.com>
128
+
Co-developed-by: Jane Doe <janedoe@email.com>
129
+
Signed-off-by: Jane Doe <janedoe@email.com>
130
+
```
131
+
132
+
> [!NOTE]
133
+
> *For those interested in where this convention comes from*
134
+
>
135
+
> Signing off commits was first adopted by the Linux Kernel after [the SCO lawsuits against IBM](https://en.wikipedia.org/wiki/SCO_Group,_Inc._v._International_Business_Machines_Corp.). One of SCO's main arguments was that the Linux Kernel used code from SCO's version of UNIX. Although this turned out to be false, the Linux Kernel project soon required developers to certify that their commits were allowed to be part of the Linux Kernel with signing off.
136
+
73
137
# Pre-Commit Hooks
74
138
To make things easier for developers, we define pre-commit hooks that allow developers to commit changes and automatically have Mypy and Black run on said commit. This is not required
75
139
Set up [pre-commit](https://pre-commit.com/). This must be installed separately and is not included in the Poetry dependencies. Then run `pre-commit install`. This will set up pre-commit hooks for the following:
0 commit comments