Contributing¶
Bug reports, feature suggestions and other contributions are greatly appreciated! pysat and pysatMadrigal are community-driven projects that welcome both feedback and contributions.
Short version¶
Submit bug reports, feature requests, and questions at GitHub Issues
Make pull requests to the
develop
branch
More about Issues¶
Bug reports, questions, and feature requests should all be made as GitHub Issues. Templates are provided for each type of issue, to help you include all the necessary information.
Questions¶
Not sure how something works? Ask away! The more information you provide, the easier the question will be to answer. You can also interact with the pysat developers on our slack channel.
Bug reports¶
When reporting a bug please include:
Your operating system name and version
Any details about your local setup that might be helpful in troubleshooting
Detailed steps to reproduce the bug
Feature requests¶
If you are proposing a new feature or a change in something that already exists:
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 code contributions are welcome :)
More about Development¶
To set up pysatMadrigal
for local development:
Fork pysatMadrigal on GitHub.
Clone your fork locally:
git clone git@github.com:your_name_here/pysatMadrigal.git
Create a branch for local development:
git checkout -b name-of-your-bugfix-or-feature
Make your changes locally. Tests for new instruments are performed automatically. Tests for custom functions should be added to the appropriately named file in
pysatMadrigal/tests
. For example, Jicamarca methods containined inpysatMadrigal/instruments/methods/jro.py
should be namedpysatMadrigal/tests/test_methods_jro.py
. If no test file exists, then you should create one. This testing uses pytest, which will run tests on any python file in the test directory that starts withtest
. Test classes must begin withTest
, and test methods must also begin withtest
.When you’re done making changes, run all the checks to ensure that nothing is broken on your local system:
pytest -vs pysatMadrigal
Update/add documentation (in
docs
). Even if you don’t think it’s relevant, check to see if any existing examples have changed.Add your name to the .zenodo.json file as an author
Commit your changes and push your branch to GitHub:
git add . git commit -m “Brief description of your changes” git push origin name-of-your-bugfix-or-feature
Submit a pull request through the GitHub website. Pull requests should be made to the
develop
branch.
Pull Request Guidelines¶
If you need some code review or feedback while you’re developing the code, just
make a pull request. Pull requests should be made to the develop
branch.
For merging, you should:
Include an example for use
Add a note to
CHANGELOG.md
about the changesEnsure that all checks passed (current checks include Travis-CI and Coveralls) 1
- 1
If you don’t have all the necessary Python versions available locally or have trouble building all the testing environments, you can rely on Travis to run the tests for each change you add in the pull request. Because testing here will delay tests by other developers, please ensure that the code passes all tests on your local system first.
Project Style Guidelines¶
In general, pysat follows PEP8 and numpydoc guidelines. Pytest runs the unit and integration tests, flake8 checks for style, and sphinx-build performs documentation tests. However, there are certain additional style elements that have been settled on to ensure the project maintains a consistent coding style. These include:
Line breaks should occur before a binary operator (ignoring flake8 W503)
Combine long strings using
join
Preferably break long lines on open parentheses rather than using
\
Use no more than 80 characters per line
Avoid using Instrument class key attribute names as unrelated variable names:
platform
,name
,tag
, andinst_id
The pysat logger is imported into each sub-module and provides status updates at the info and warning levels (as appropriate)
Several dependent packages have common nicknames, including:
import datetime as dt
import numpy as np
import pandas as pds
import xarray as xr
All classes should have
__repr__
and__str__
functionsDocstrings use
Note
instead ofNotes
Try to avoid creating a try/except statement where except passes
Use setup and teardown in test classes
Use pytest parametrize in test classes when appropriate
Provide testing class methods with informative failure statements and descriptive, one-line docstrings
Block and inline comments should use proper English grammar and punctuation with the exception of single sentences in a block, which may then omit the final period
- When casting is necessary, use
np.int64
andnp.float64
to ensure operating system agnosticism
- When casting is necessary, use