Contributions are highly welcomed and appreciated. Every little help counts,
so do not hesitate! You can make a high impact on
esmtools just by using it and
The following sections cover some general guidelines
regarding development in
esmtools for maintainers and contributors.
Nothing here is set in stone and can’t be changed.
Feel free to suggest improvements or changes in the workflow.
We are eager to hear about your requests for new features and any suggestions about the API, infrastructure, and so on. Feel free to submit these as issues with the label “feature request.”
Please make sure to explain in detail how the feature should work and keep the scope as narrow as possible. This will make it easier to implement in small PRs.
Report bugs for
esmtools in the issue tracker
with the label “bug”.
If you are reporting a bug, please include:
- Your operating system name and version.
- Any details about your local setup that might be helpful in troubleshooting,
specifically the Python interpreter version, installed libraries, and
- Detailed steps to reproduce the bug.
If you can write a demonstration test that currently fails but should passm that is a very useful commit to make as well, even if you cannot fix the bug itself.
Look through the GitHub issues for bugs.
Talk to developers to find out how you can fix specific bugs.
esmtools could always use more documentation. What exactly is needed?
- More complementary documentation. Have you perhaps found something unclear?
- Docstrings. There can never be too many of them.
- Example notebooks with different Earth System Models, lead times, etc. – they’re all very appreciated.
You can also edit documentation files directly in the GitHub web interface, without using a local copy. This can be convenient for small fixes.
Build the documentation locally with the following command:
$ conda env update -f ci/environment-dev-3.6.yml $ cd docs $ make html
The built documentation should be available in the
If you need to add new functions to the API, add the functions to
api.rst then run
sphinx-autogen -o api api.rst from the
docs/source directory. You might need to run
make clean from the
docs/ directory and then
make html again to get the links to build properly.
Fork the esmtools GitHub repository. It’s fine to use
esmtoolsas your fork repository name because it will live under your user.
Clone your fork locally using git, connect your repository to the upstream (main project), and create a branch:
$ git clone firstname.lastname@example.org:YOUR_GITHUB_USERNAME/esmtools.git $ cd esmtools $ git remote add upstream email@example.com:bradyrx/esmtools.git # now, to fix a bug or add feature create your own branch off "master": $ git checkout -b your-bugfix-feature-branch-name master
If you need some help with Git, follow this quick start guide: https://git.wiki.kernel.org/index.php/QuickStart
Install dependencies into a new conda environment:
$ conda env update -f ci/environment-dev-3.7.yml $ conda activate esmtools-dev
Make an editable install of esmtools by running:
$ pip install -e .
Install pre-commit and its hook on the
$ pip install --user pre-commit $ pre-commit install
pre-commitwill run whenever you commit.
https://pre-commit.com/ is a framework for managing and maintaining multi-language pre-commit hooks to ensure code-style and code formatting is consistent.
Now you have an environment called
esmtools-devthat you can work in. You’ll need to make sure to activate that environment next time you want to use it after closing the terminal or your system.
You can now edit your local working copy and run/add tests as necessary. Please follow PEP-8 for naming. When committing,
pre-commitwill modify the files as needed, or will generally be quite clear about what you need to do to pass the commit test.
Break your edits up into reasonably sized commits.
$ git commit -a -m “<commit message>” $ git push -u
Run all the tests
Now running tests is as simple as issuing this command:
$ coverage run --source esmtools -m py.test
This command will run tests via the “pytest” tool against Python 3.6.
Create a new changelog entry in
- The entry should be entered as:
:pr:`#<pull request number>`)
<description>is the description of the PR related to the change and
<pull request number>is the pull request number and
<author's names>are your first and last names.
- Add yourself to list of authors at the end of
CHANGELOG.rstfile if not there yet, in alphabetical order.
Add yourself to the contributors <https://esmtools.readthedocs.io/en/latest/contributors.html>_ list via
Finally, submit a pull request through the GitHub website using this data:
head-fork: YOUR_GITHUB_USERNAME/esmtools compare: your-branch-name
base-fork: bradyrx/esmtools base: master
Note that you can create the Pull Request while you’re working on this. The PR will update
as you add more commits.
esmtools developers and contributors can then review your code
and offer suggestions.