|
| 1 | +# Contributing |
| 2 | +Contributions are welcome! Make sure to first open an issue discussing the problem or the new feature before creating a pull request. This project uses [poetry](https://python-poetry.org/). |
| 3 | + |
| 4 | +## Code Style |
| 5 | +The code follows the [black](https://github.com/psf/black) code style. Import statements are sorted with [isort](https://pycqa.github.io/isort/). The project must type-check with [pyright](https://github.com/microsoft/pyright). It is recommend to run the type-checker via the VSCode Python extension (discussed below). |
| 6 | + |
| 7 | +**Format** |
| 8 | +```bash |
| 9 | +# omit `poetry run` if u have the virtualenv activated |
| 10 | +$ poetry run isort beet_observer |
| 11 | +$ poetry run black beet_observer |
| 12 | +``` |
| 13 | + |
| 14 | +**Check** |
| 15 | +```bash |
| 16 | +# omit `poetry run` if u have the virtualenv activated |
| 17 | +$ poetry run black --check beet_observer |
| 18 | +$ poetry run isort --check-only beet_observer |
| 19 | +``` |
| 20 | + |
| 21 | +You can run `poetry self add 'poethepoet[poetry_plugin]'` to get access to an easier set of commands: |
| 22 | +```bash |
| 23 | +# omit `poetry` if u have the virtualenv activated |
| 24 | +$ poetry poe format |
| 25 | +$ poetry poe check |
| 26 | +``` |
| 27 | + |
| 28 | +## IDE |
| 29 | +It is recommend to use [VSCode](https://code.visualstudio.com/). The following recommendations are made for python contributions. |
| 30 | + |
| 31 | +### Python |
| 32 | +It is recommend to use the official [Python](https://marketplace.visualstudio.com/items?itemName=ms-python.python) extension. This extension comes with type-checking support alongside automatic formatting and import sorting. |
| 33 | + |
| 34 | +## Commits |
| 35 | +When committing code, follow the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) style for writing commit messages: |
| 36 | + |
| 37 | +```md |
| 38 | +<type>: <subject> |
| 39 | +<BLANK LINE> |
| 40 | +<body> |
| 41 | +<BLANK LINE> |
| 42 | +<footer> |
| 43 | +``` |
| 44 | + |
| 45 | +### Examples |
| 46 | +- feat: added support for multiple overlay definitions |
| 47 | +- docs: add usage information |
| 48 | +- fix: folder generates in incorrect location |
| 49 | +- feat!: added support for multiple overlay definitions |
| 50 | + |
| 51 | +> Note |
| 52 | +
|
| 53 | +Here are the types used (adapted from [here](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)): |
| 54 | + |
| 55 | + |
| 56 | +### Types |
| 57 | +> **type** [*version*]: description |
| 58 | +
|
| 59 | +- **feat** [*minor*]: A new feature |
| 60 | +- **fix** [*patch*]: A bug fix |
| 61 | +- **perf** [*patch*]: A code change that improves performance |
| 62 | +- **docs**: Documentation only changes |
| 63 | +- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
| 64 | +- **refactor**: A code change that neither fixes a bug nor adds a feature |
| 65 | +- **test**: Adding missing or correcting existing tests |
| 66 | +- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation |
| 67 | + |
| 68 | + |
| 69 | +### Extras |
| 70 | +- The start of `<body>` or `<footer>` can be `BREAKING CHANGE:` to indicate a **major** version bump |
| 71 | +- Keep each line under 100 characters |
| 72 | + |
| 73 | + |
| 74 | +## Versioning |
| 75 | +This project follows the [semantic versioning](https://semver.org/) format for versioning: |
| 76 | +- `major` reserved for breaking changes (needs maintainer approval) |
| 77 | +- `minor` for new features and larger tweaks (usually changing user experience like adding an option to the config) |
| 78 | +- `patch` for bug fixes and smaller tweaks (usually doesn't affect user experience) |
| 79 | + |
| 80 | +> The commit type indicates whether a bump should be `patch` or `minor`. The version will be updated automatically based on the commit. |
0 commit comments