The xarray-eopf welcomes contributions of any form as long as you respect our code of conduct and stay in line with the following instructions and guidelines.
If you have suggestions, ideas, feature requests, or if you have identified a malfunction or error, then please post an issue.
If you'd like to submit code or documentation changes, we ask you to provide a pull request (PR) here. For code and configuration changes, your PR must be linked to a corresponding issue.
To ensure that your code contributions are consistent with our project’s coding guidelines, please make sure all applicable items of the following checklist are addressed in your PR.
PR checklist
- Format and check code using ruff with
default settings:
ruff formatandruff check. See also section code style below. - Your change shall not break existing unit tests.
pytestmust run without errors. - Add unit tests for any new code not yet covered by tests.
- Make sure test coverage stays close to 100% for any change.
Use
pytest --cov=xarray_eopf --cov-report=htmlto verify. - If your change affects the current project documentation,
please adjust it and include the change in the PR.
Run
mkdocs serveto verify.
The code style of xarray-eopf equals the default settings of black. Since black is un-opinionated regarding the order of imports, we group and sort imports statements according to the default settings of isort which boils down to
- Future imports
- Python standard library imports, e.g.,
os,typing, etc - 3rd-party imports, e.g.,
xarray,zarr, etc - 1st-party library module imports using absolute paths,
e.g.,
from xarray_eopf.a.b.c import d. - 1st-party library module imports from local modules:
Relative imports such as
from .c import dare ok while..c import dare not ok.
Use typing.TYPE_CHECKING to resolve forward references
and effectively avoid circular dependencies.
Package classes, functions, constants, type aliases considered public API should have docstrings according to the Google Style.