|
| 1 | +# DVE Contributing guidelines |
| 2 | + |
| 3 | +# Developer information |
| 4 | + |
| 5 | +## Getting started |
| 6 | + |
| 7 | +To begin with I would recommend that users read all the documentation available within the [docs](./docs/). It gives an overview of how the DVE works and how to work with the dischema json document. |
| 8 | + |
| 9 | +## General requirements |
| 10 | +To start contributing to the DVE project you will need the following tooling available: |
| 11 | +| Tool | Version | Reason | |
| 12 | +| ---- | ------- | ------ | |
| 13 | +| `Python` | 3.7.17 | Currently supported version of `Python` for the DVE. | |
| 14 | +| `Poetry` | 1.4.2 | Build and venv tool used for the DVE. | |
| 15 | +| `Java` | java liberica-1.8.0 | `Java` version required for `PySpark`. | |
| 16 | +| `pre-commit` | 2.21.0 | Currently installed as part of the `poetry` venv but seperate installation is fine. | |
| 17 | +| `commitizen` | 3.9.1 | Like `pre-commit`, installed as part of the `poetry` venv but seperate installation is fine. This is used to manage commits and automated semantic versioning. | |
| 18 | +| `git-secrets` | Latest | Utilised as part of the `pre-commit` to ensure that no secrets are commited to the repository. There is a helper installation script within [scripts](/scripts/git-secrets/). | |
| 19 | + |
| 20 | +Additionally, we have created a [asdf support](.tool-versions) and [mise-en-toml](.mise.toml) for those utilising `asdf` or `mise-en-toml` software. |
| 21 | + |
| 22 | +## Testing Requirements |
| 23 | + |
| 24 | +Testing requirements are given in [pyproject.toml](./poetry.toml#48) under `tool.poetry.group.test.dependencies`. These are always pinned versions for consistency, but should be updated regularly if new versions are released. The following core packages are used for testing: |
| 25 | + - [pytest](https://docs.pytest.org/en/stable/): Used for Python unit tests, and some small e2e tests which check coverage. |
| 26 | + - [behave](https://github.com/behave/behave): Used for full, business-driven end-to-end tests. |
| 27 | + - [coverage](https://coverage.readthedocs.io/en/7.10.7/): Used to get coverage for `pytest` tests. |
| 28 | + |
| 29 | +## Linting/Formatting/Type Checking Requirements |
| 30 | + |
| 31 | +Additional dependencies for linting, type checking, and formatting are listed within the [pyproject.toml](./poetry.toml#58) under `tool.poetry.group.lint.dependencies`. Like the testing requirements, we use pinned versions for these. |
| 32 | + |
| 33 | +This mostly breaks down to: |
| 34 | +- [black](https://github.com/psf/black): a tool to format Python, which ensures consistency of formatting across the project. We use a line length of 100. |
| 35 | +- [isort](https://pycqa.github.io/isort/): a tool to organise imports in a consistent way across the project. |
| 36 | +- [mypy](https://github.com/python/mypy): a type checker for Python. This ensures that our function signatures remain accurate and is very useful for spotting type-related issues (a significant category of bugs). |
| 37 | +- [pylint](https://pylint.readthedocs.io/en/stable/): a (very aggressive) linter for Python, which prevents errors and code style violations across the project. This pushes us to document the code and is often quite good at highlighting overly complex code. |
| 38 | + |
| 39 | +We use these tools to ensure that code quality is not excessively compromised, even when working at pace. |
| 40 | + |
| 41 | +## Installation for Development |
| 42 | + |
| 43 | +We are utilising Poetry for build dependency management and packaging. If you're on a system that has `Make` available, you can simply run `make install` to setup a local virtual environment with all the dependencies installed (this won't install Poetry for you). |
| 44 | + |
| 45 | +## Testing |
| 46 | + |
| 47 | +Tests should be run after installing the package for development as outlined above. |
| 48 | +- To run unit tests without coverage, run `poetry run pytest tests/` |
| 49 | +- To run the unit tests with coverage, run `poetry run coverage run` |
| 50 | +- To check the coverage run `poetry run coverage report -m` |
| 51 | +- To run the behave tests, run `poetry run behave tests/features` (these are not included in coverage calculations) |
| 52 | + |
| 53 | +## Submitting a pull request |
| 54 | + |
| 55 | +If you want to contribute to the DVE then please follow the steps below: |
| 56 | +1. Fork the repository. |
| 57 | +2. Configure and install the dependencies. |
| 58 | +3. Ensure that new changes are fully tested and that you are reguarlly checking for changes within the DVE repository to sort any potential merge conflicts. |
| 59 | +4. Ensure linting passes. |
| 60 | +5. Push and then create a pull request from your fork to our repository. |
| 61 | + |
| 62 | +Your pull request will then be reviewed. You may receive some feedback and suggested changes before it can be approved and merged. |
0 commit comments