Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
You can contribute in many ways to any of the packages that are included in HyRiver
project. The workflow is the same for all packages. In this page, a contribution workflow
for PyGridMET is explained. You can easily
adapt it to other packages by replacing pygridmet
with the name of the package
that you want to contribute to.
Report bugs at https://github.com/hyriver/pygridmet/issues.
Look through the GitHub issues for bugs. Anything tagged with "bug" and "help wanted" is open to whoever wants to implement it.
Other than new features that you might have in mind, you can look through the GitHub issues for features. Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.
PyGridMET could always use more documentation, whether as part of the official PyGridMET docs, in docstrings, or even on the web in blog posts, articles, and such.
The best way to send feedback is to file an issue at https://github.com/hyriver/pygridmet/issues.
If you are proposing a feature:
- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions are welcome :)
Ready to contribute? Here's how to set up pygridmet for local development.
- Fork the PyGridMET repo through the GitHub website.
- Clone your fork locally and add the main
pygridmet
as the upstream remote:
$ git clone git@github.com:your_name_here/pygridmet.git
$ git remote add upstream git@github.com:hyriver/pygridmet.git
- Install your local copy into a virtualenv. Assuming you have
mamba
installed, this is how you can set up your fork for local development:
$ cd pygridmet/
$ mamba env create -f ci/requirements/environment-dev.yml
$ mamba activate pygridmet-dev
$ python -m pip install . --no-deps
- Create a branch for local development:
$ git checkout -b bugfix-or-feature/name-of-your-bugfix-or-feature
$ git push
- Now you can make your changes locally, make sure to add a description of
the changes to
HISTORY.rst
file and add extra tests, if applicable, totests
folder. Also, make sure to give yourself credit by adding your name at the end of the item(s) that you add in the history like thisBy `Taher Chegini <https://github.com/hyriver>`_
. Then, fetch the latest updates from the remote and resolve any merge conflicts:
$ git fetch upstream
$ git merge upstream/name-of-your-branch
- Then create a new environment for linting and another for testing:
$ mamba create -n py11 python=3.11 nox tomli pre-commit codespell gdal
$ mamba activate py11
$ nox -s pre-commit
$ nox -s type-check
$ mamba create -n py38 python=3.8 nox tomli pre-commit codespell gdal
$ mamba activate py38
$ nox -s tests
Note that if Python 3.11 is already installed on your system, you can
skip creating the ``py11`` environment and just use your system's Python 3.11
to run the linting and type-checking tests, like this:
$ mamba create -n py38 python=3.8 nox tomli pre-commit codespell gdal
$ mamba activate py38
$ nox
- If you are making breaking changes make sure to reflect them in
the documentation,
README.rst
, and tests if necessary. - Commit your changes and push your branch to GitHub. Start the commit message with
ENH:
,BUG:
,DOC:
to indicate whether the commit is a new feature, documentation related, or a bug fix. For example:
$ git add .
$ git commit -m "ENH: A detailed description of your changes."
$ git push origin name-of-your-branch
- Submit a pull request through the GitHub website.
To run a subset of tests:
$ nox -s tests -- -n=1 -k "test_name1 or test_name2"
A reminder for the maintainers on how to deploy. Make sure all your changes are committed (including an entry in HISTORY.rst). Then run:
$ git tag -a vX.X.X -m "vX.X.X"
$ git push --follow-tags
where X.X.X
is the version number following the
semantic versioning spec i.e., MAJOR.MINOR.PATCH.
Then release the tag from Github and Github Actions will deploy it to PyPi.