|
| 1 | +# Developer Intro |
| 2 | + |
| 3 | +pdfly is an application and thus non-developers |
| 4 | +might also use it. |
| 5 | + |
| 6 | +## Installing Requirements |
| 7 | + |
| 8 | +``` |
| 9 | +pip install -r requirements/dev.txt |
| 10 | +``` |
| 11 | + |
| 12 | +## Running Tests |
| 13 | + |
| 14 | +See [testing pdfly with pytest](testing.md) |
| 15 | + |
| 16 | +## Tools: git and pre-commit |
| 17 | + |
| 18 | +Git is a command line application for version control. If you don't know it, |
| 19 | +you can [play ohmygit](https://ohmygit.org/) to learn it. |
| 20 | + |
| 21 | +GitHub is the service where the pdfly project is hosted. While git is free and |
| 22 | +open source, GitHub is a paid service by Microsoft, but free in a lot of |
| 23 | +cases. |
| 24 | + |
| 25 | +[pre-commit](https://pypi.org/project/pre-commit/) is a command line application |
| 26 | +that uses git hooks to automatically execute code. This allows you to avoid |
| 27 | +style issues and other code quality issues. After you entered `pre-commit install` |
| 28 | +once in your local copy of pdfly, it will automatically be executed when |
| 29 | +you `git commit`. |
| 30 | + |
| 31 | +## Commit Messages |
| 32 | + |
| 33 | +Having a clean commit message helps people to quickly understand what the commit |
| 34 | +is about, without actually looking at the changes. The first line of the |
| 35 | +commit message is used to [auto-generate the CHANGELOG](https://github.com/py-pdf/pdfly/blob/main/make_release.py). |
| 36 | +For this reason, the format should be: |
| 37 | + |
| 38 | +``` |
| 39 | +PREFIX: DESCRIPTION |
| 40 | +
|
| 41 | +BODY |
| 42 | +``` |
| 43 | + |
| 44 | +The `PREFIX` can be: |
| 45 | + |
| 46 | +* `SEC`: Security improvements. Typically an infinite loop that was possible. |
| 47 | +* `BUG`: A bug was fixed. Likely there is one or multiple issues. Then write in |
| 48 | + the `BODY`: `Closes #123` where 123 is the issue number on GitHub. |
| 49 | + It would be absolutely amazing if you could write a regression test in those |
| 50 | + cases. That is a test that would fail without the fix. |
| 51 | + A bug is always an issue for pdfly users - test code or CI that was fixed is |
| 52 | + not considered a bug here. |
| 53 | +* `ENH`: A new feature! Describe in the body what it can be used for. |
| 54 | +* `DEP`: A deprecation. Either marking something as "this is going to be removed" |
| 55 | + or actually removing it. |
| 56 | +* `PI`: A performance improvement. This could also be a reduction in the |
| 57 | + file size of PDF files generated by pdfly. |
| 58 | +* `ROB`: A robustness change. Dealing better with broken PDF files. |
| 59 | +* `DOC`: A documentation change. |
| 60 | +* `TST`: Adding or adjusting tests. |
| 61 | +* `DEV`: Developer experience improvements, e.g. pre-commit or setting up CI. |
| 62 | +* `MAINT`: Quite a lot of different stuff. Performance improvements are for sure |
| 63 | + the most interesting changes in here. Refactorings as well. |
| 64 | +* `STY`: A style change. Something that makes pdfly code more consistent. |
| 65 | + Typically a small change. It could also be better error messages for |
| 66 | + end users. |
| 67 | + |
| 68 | +The prefix is used to generate the CHANGELOG. Every PR must have exactly one - |
| 69 | +if you feel like several match, take the top one from this list that matches for |
| 70 | +your PR. |
| 71 | + |
| 72 | +## Pull Request Size |
| 73 | + |
| 74 | +Smaller Pull Requests (PRs) are preferred as it's typically easier to merge |
| 75 | +them. For example, if you have some typos, a few code-style changes, a new |
| 76 | +feature, and a bug-fix, that could be 3 or 4 PRs. |
| 77 | + |
| 78 | +A PR must be complete. That means if you introduce a new feature it must be |
| 79 | +finished within the PR and have a test for that feature. |
0 commit comments