-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #75 from pysat/rc_0_3_0
Release Candidate 0.3.0
- Loading branch information
Showing
34 changed files
with
1,126 additions
and
429 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,16 +4,21 @@ Contributing | |
Bug reports, feature suggestions and other contributions are greatly | ||
appreciated! pysatMissions is a community-driven project and welcomes both feedback and contributions. | ||
|
||
Come join us on Slack! An invitation to the pysat workspace is available | ||
in the 'About' section of the | ||
[pysat GitHub Repository.](https://github.com/pysat/pysat) Development meetings | ||
are generally held fortnightly. | ||
|
||
Short version | ||
------------- | ||
|
||
* Submit bug reports and feature requests at `GitHub <https://github.com/pysat/pysatMissions/issues>`_ | ||
* Submit bug reports and feature requests at [GitHub](https://github.com/pysat/pysatMissions/issues) | ||
* Make pull requests to the ``develop`` branch | ||
|
||
Bug reports | ||
----------- | ||
|
||
When `reporting a bug <https://github.com/pysat/pysatMissions/issues>`_ please | ||
When [reporting a bug](https://github.com/pysat/pysatMissions/issues) please | ||
include: | ||
|
||
* Your operating system name and version | ||
|
@@ -24,7 +29,7 @@ Feature requests and feedback | |
----------------------------- | ||
|
||
The best way to send feedback is to file an issue at | ||
`GitHub <https://github.com/pysat/pysatMissions/issues>`_. | ||
[GitHub](https://github.com/pysat/pysatMissions/issues). | ||
|
||
If you are proposing a feature: | ||
|
||
|
@@ -38,14 +43,17 @@ Development | |
|
||
To set up `pysatMissions` for local development: | ||
|
||
1. `Fork pysat on GitHub <https://github.com/pysat/pysatMissions/fork>`_. | ||
2. Clone your fork locally:: | ||
|
||
git clone [email protected]:your_name_here/pysatMissions.git | ||
1. [Fork pysat on GitHub](https://github.com/pysat/pysatMissions/fork). | ||
|
||
3. Create a branch for local development:: | ||
3. Clone your fork locally: | ||
``` | ||
git clone [email protected]:your_name_here/pysatMissions.git | ||
``` | ||
|
||
git checkout -b name-of-your-bugfix-or-feature | ||
3. Create a branch for local development: | ||
``` | ||
git checkout -b name-of-your-bugfix-or-feature | ||
``` | ||
|
||
Now you can make your changes locally. Tests for new instruments are | ||
performed automatically. Tests for custom functions should be added to | ||
|
@@ -55,19 +63,31 @@ To set up `pysatMissions` for local development: | |
``test_``. | ||
|
||
4. When you're done making changes, run all the checks to ensure that nothing | ||
is broken on your local system:: | ||
|
||
pytest -vs | ||
is broken on your local system: | ||
``` | ||
pytest -vs | ||
``` | ||
|
||
5. Update/add documentation (in ``docs``), if relevant | ||
|
||
5. Commit your changes and push your branch to GitHub:: | ||
6. Add your name to the .zenodo.json file as an author | ||
|
||
7. Commit your changes: | ||
``` | ||
git add . | ||
git commit -m "AAA: Brief description of your changes" | ||
``` | ||
Where AAA is a standard shorthand for the type of change (eg, BUG or DOC). | ||
`pysat` follows the [numpy development workflow](https://numpy.org/doc/stable/dev/development_workflow.html), | ||
see the discussion there for a full list of this shorthand notation. | ||
|
||
git add . | ||
git commit -m "Brief description of your changes" | ||
git push origin name-of-your-bugfix-or-feature | ||
8. Once you are happy with the local changes, push to Github: | ||
``` | ||
git push origin name-of-your-bugfix-or-feature | ||
``` | ||
Note that each push will trigger the Continuous Integration workflow. | ||
|
||
6. Submit a pull request through the GitHub website. Pull requests should be | ||
9. Submit a pull request through the GitHub website. Pull requests should be | ||
made to the ``develop`` branch. | ||
|
||
Pull Request Guidelines | ||
|
@@ -81,45 +101,45 @@ For merging, you should: | |
1. Include an example for use | ||
2. Add a note to ``CHANGELOG.md`` about the changes | ||
3. Ensure that all checks passed (current checks include GitHub Actions | ||
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 | ||
GitHub Actions 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`, and `inst_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__` functions | ||
* Docstrings use `Note` instead of `Notes` | ||
* 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` and `np.float64` to ensure operating | ||
system agnosticism | ||
and Coveralls) | ||
|
||
If you don't have all the necessary Python versions available locally or | ||
have trouble building all the testing environments, you can rely on | ||
the project's Continuous Integration (CI) service 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`, and `inst_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__` functions | ||
* Docstrings use `Note` instead of `Notes` | ||
* 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` and `np.float64` to ensure operating | ||
system agnosticism |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.