Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a pre-commit configuration file #23

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
ci:
autofix_prs: false
autoupdate_schedule: quarterly

exclude: .*\.dot|.*\.svg

repos:

- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.6.0
hooks:
- id: trailing-whitespace
- id: check-case-conflict
- id: end-of-file-fixer
- id: check-yaml
- id: check-merge-conflict

- repo: https://github.com/sirosen/texthooks
rev: 0.6.7
hooks:
- id: fix-smartquotes
- id: fix-spaces
- id: fix-ligatures
- id: forbid-bidi-controls

- repo: https://github.com/pre-commit/pygrep-hooks
rev: v1.10.0
hooks:
- id: text-unicode-replacement-char

- repo: https://github.com/macisamuele/language-formatters-pre-commit-hooks
rev: v2.14.0
hooks:
- id: pretty-format-yaml
args: [--autofix]

- repo: https://github.com/python-jsonschema/check-jsonschema
rev: 0.29.2
hooks:
- id: check-github-workflows

- repo: https://github.com/crate-ci/typos
rev: v1.24.6
hooks:
- id: typos
166 changes: 83 additions & 83 deletions .zenodo.json
Original file line number Diff line number Diff line change
@@ -1,167 +1,167 @@
{
"language": "eng",
"license": "Apache-2.0",
"title": "Python in Heliophysics Community (PyHC) Standards",
"language": "eng",
"license": "Apache-2.0",
"title": "Python in Heliophysics Community (PyHC) Standards",
"related_identifiers": [
{
"scheme": "url",
"identifier": "https://github.com/heliophysicsPy/standards/tree/v1.0",
"scheme": "url",
"identifier": "https://github.com/heliophysicsPy/standards/tree/v1.0",
"relation": "isSupplementTo"
},
},
{
"scheme": "doi",
"identifier": "10.5281/zenodo.2529130",
"scheme": "doi",
"identifier": "10.5281/zenodo.2529130",
"relation": "isVersionOf"
}
],
"publication_type": "softwaredocumentation",
"version": "v1.0",
"upload_type": "publication",
],
"publication_type": "softwaredocumentation",
"version": "v1.0",
"upload_type": "publication",
"keywords": [
"standards",
"heliophysics",
"standards",
"heliophysics",
"python"
],
"publication_date": "2018-12-31",
],
"publication_date": "2018-12-31",
"creators": [
{
"affiliation": "@JHU",
"affiliation": "@JHU",
"name": "Annex, A."
},
},
{
"affiliation": "@Univ. of Michigan",
"affiliation": "@Univ. of Michigan",
"name": "Alterman, B. L.",
"orcid": "0000-0001-6673-3432",
},
},
{
"affiliation": "@Univ. of Michigan",
"affiliation": "@Univ. of Michigan",
"name": "Azari, A. R.",
"orcid": "0000-0002-8665-5459"
},
},
{
"affiliation": "@Rice Univ.",
"affiliation": "@Rice Univ.",
"name": "Barnes, W."
},
},
{
"affiliation": "@Stanford",
"affiliation": "@Stanford",
"name": "Bobra, M."
},
},
{
"affiliation": "@Observatoire de Paris",
"affiliation": "@Observatoire de Paris",
"name": "Cecconi, B.",
"orcid": "0000-0001-7915-5571"
},
{
"orcid": "0000-0001-6127-795X",
"affiliation": "@NASA-GSFC",
"orcid": "0000-0001-6127-795X",
"affiliation": "@NASA-GSFC",
"name": "Christe, Steven"
},
},
{
"affiliation": "@Univ. of Southampton",
"affiliation": "@Univ. of Southampton",
"name": "Coxon, J."
},
},
{
"affiliation": "@LASP",
"affiliation": "@LASP",
"name": "DeWolfe, A."
},
},
{
"affiliation": "@Aerospace Corporation",
"affiliation": "@Aerospace Corporation",
"name": "Halford, A."
},
},
{
"affiliation": "@LASP",
"affiliation": "@LASP",
"name": "Harter, B."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Ireland, J."
},
},
{
"affiliation": "@SWRI",
"affiliation": "@SWRI",
"name": "Jahn, J."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Klenzing, J."
"orcid": "0000-0001-8321-6074"
},
},
{
"affiliation": "@SunPy",
"affiliation": "@SunPy",
"name": "Liu, M."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Mason, J."
"orcid": "0000-0002-3783-5509"
},
},
{
"affiliation": "@NASA-JPL",
"affiliation": "@NASA-JPL",
"name": "McGranaghan, R."
},
{
"orcid": "0000-0003-4217-4642",
"affiliation": "@Aperio Software",
"orcid": "0000-0003-4217-4642",
"affiliation": "@Aperio Software",
"name": "Mumford, Stuart"
},
},
{
"affiliation": "@Center for Astrophysics | Harvard & Smithsonian",
"affiliation": "@Center for Astrophysics | Harvard & Smithsonian",
"name": "Murphy, N. A.",
"orcid": "0000-0001-6628-8033",
},
},
{
"affiliation": "@Trinity College Dublin",
"affiliation": "@Trinity College Dublin",
"name": "Murray, S."
},
},
{
"affiliation": "@Univ. of New Hampshire",
"affiliation": "@Univ. of New Hampshire",
"name": "Niehof, J."
},
},
{
"affiliation": "@Lomonosov Moscow State Univ.",
"affiliation": "@Lomonosov Moscow State Univ.",
"name": "Nguyen, M. D."
},
},
{
"affiliation": "@LASP",
"affiliation": "@LASP",
"name": "Panneton, R."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Pembroke, A."
},
},
{
"affiliation": "@University College London",
"affiliation": "@University College London",
"name": "P\u00e9rez-Su\u00e1rez, D."
},
},
{
"affiliation": "@Univ. of Iowa",
"affiliation": "@Univ. of Iowa",
"name": "Piker, C."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Roberts, A."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Ryan, D."
},
},
{
"affiliation": "@NASA-MSFC",
"affiliation": "@NASA-MSFC",
"name": "Savage, S."
},
},
{
"affiliation": "@NASA-GSFC",
"affiliation": "@NASA-GSFC",
"name": "Smith, J."
},
},
{
"affiliation": "@Imperial College London",
"affiliation": "@Imperial College London",
"name": "Stansby, D."
},
},
{
"affiliation": "@JHU",
"affiliation": "@JHU",
"name": "Vandegriff, J."
},
},
{
"affiliation": "@George Mason University",
"affiliation": "@George Mason University",
"name": "Weigel, R. S.",
"orcid": "0000-0002-9521-5228"
},
Expand All @@ -170,7 +170,7 @@
"name": "Yu, S.",
"orcid": "0000-0003-2872-2614"
}
],
"access_right": "open",
],
"access_right": "open",
"description": "<p>A set of standards for the Python in Heliophysics Community.</p>"
}
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# Purpose
The purpose of this repository is to store the Python in Heliophysics Community (PyHC) Standards.
The purpose of this repository is to store the Python in Heliophysics Community (PyHC) Standards.
This is the canonical version.


Expand Down
2 changes: 1 addition & 1 deletion pheps/phep-0001.md
Original file line number Diff line number Diff line change
Expand Up @@ -349,7 +349,7 @@ As originally proposed PHEPs were limited to ASCII where practicable. This was d

## Immutability of PHEPs
<a name="immutability-of-pheps"></a>
As currently written, PHEPs are laregly [immutable](#phep-maintenance) once Final. Substantive changes require replacement rather than modification. This maintains clarity of reference, "PHEP-x" rather than "PHEP-x version y", and avoids confusion arising from rolling updates. It encourages getting the PHEP correct before first acceptance. Finally, it removes the need to define and document an update process.
As currently written, PHEPs are largely [immutable](#phep-maintenance) once Final. Substantive changes require replacement rather than modification. This maintains clarity of reference, "PHEP-x" rather than "PHEP-x version y", and avoids confusion arising from rolling updates. It encourages getting the PHEP correct before first acceptance. Finally, it removes the need to define and document an update process.

A PHEP can be updated by introducing a new PHEP that starts with and builds on the original text. Everything is then open for discussion. This encourages complete re-evaluation if the community reaches the point where something is important enough to revisit.

Expand Down
11 changes: 5 additions & 6 deletions standards.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,33 +8,32 @@ Drafted during the Heliopython Meeting of November 2018.

---

Agreed on 10-Dec-2018 by (in alpahbetical order)
Agreed on 10-Dec-2018 by (in alphabetical order)

**A. Annex** (JHU), **B. L. Alterman** (Univ. of Michigan), **A. Azari** (Univ. of Michigan), **W. Barnes** (Rice Univ.), **M. Bobra** (Stanford), **B. Cecconi** (Observatoire de Paris), **S. Christe** (NASA GSFC), **J. Coxon** (Univ. of Southampton), **A. DeWolfe** (LASP), **A. Halford** (Aerospace Corporation), **B. Harter** (LASP), **J. Ireland** (NASA GSFC), **J. Jahn** (SwRI), **J. Klenzing** (NASA GSFC), **M. Liu** (SunPy), **J. Mason** (NASA GSFC), **R. McGranaghan** (NASA JPL), **S. Mumford** (Aperio Software), **N. Murphy** (CfA), **S. Murray** (Trinity College Dublin), **J. Niehof** (Univ. of New Hampshire), **M.D. Nguyen** (Lomonosov Moscow State Univ.), **R. Panneton** (CU/LASP), **A. Pembroke** (NASA GSFC), **D. Pérez-Suárez** (University College London), **C. Piker** (Univ. of Iowa), **A. Roberts** (NASA GSFC), **D. Ryan** (NASA GSFC), **S. Savage** (NASA GSFC), **J. Smith** (NASA GSFC, Catholic Univ.), **D. Stansby** (Imperial College London), **J. Vandegriff** (JHU/APL), **R. S. Weigel** (George Mason University), **S. Yu** (NJIT)

---

Definitions:
* Use of the word **must** means that it is a requirement.
* Use of the word **should** means that it is a recommendation.
* Use of the word "**must**" means that it is a requirement.
* Use of the word "**should**" means that it is a recommendation.
* **Packages** - A package is a collection of Python modules which provide related functionality.
* **Stable Package** - A package whose functionality and user interface is not planned on changing until the next major release.

## Standards

1. **Packaging**: All code must be organized and provided as part of installable Python packages.
2. **Open Development**: All code must be made available and developed publicly.
3. **Releases**: Projects should strive to have consistent and stable releases. Those releases should be made available through [PyPI](https://pypi.org/) and [Conda](https://conda.io/docs/). Code that is not yet stable must have a release number that is less than 1.0 (e.g. 0.x). Packages should consider using [semantic versioning](https://www.semver.org).
3. **Releases**: Projects should strive to have consistent and stable releases. Those releases should be made available through [PyPI](https://pypi.org/) and [Conda](https://conda.io/docs/). Code that is not yet stable must have a release number that is less than 1.0 (e.g. 0.x). Packages should consider using [semantic versioning](https://www.semver.org).
4. **Operating System Support**: Packages must strive to support all major operating systems (e.g., OS X, Linux, Windows).
5. **License**: Projects must provide a license. Projects should use permissive licenses for open source scientific software (e.g., the BSD 2-clause, BSD 3-clause, or BSD+Patent licenses). Copyleft licenses such as GPL are not recommended and OSI-approved permissive licenses are recommended.
6. **Version control**: All code must use version control. It is strongly recommended that projects make use of a distributed version control system (e.g., git).
7. **Coding Style**: Projects must adopt the basic style recommendations of [PEP 8](https://www.python.org/dev/peps/pep-0008/) and static analysis tools should be used to identify deviations from the basic style recommendations (e.g. pylint, flake8, pycodestyle).
8. **Documentation**: All functions, classes, and modules must have documentation strings (docstrings) provided in a standard [conventions](https://www.python.org/dev/peps/pep-0257/) (e.g. [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html)). Docstrings must describe the codes purpose, describe all inputs and outputs, and provide examples. High level documentation must also be provided as guides, tutorials, and developer docs. Documentation must be provided in version control with the code and be made available online in a readable form.
8. **Documentation**: All functions, classes, and modules must have documentation strings (docstrings) provided in a standard [conventions](https://www.python.org/dev/peps/pep-0257/) (e.g. [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html)). Docstrings must describe the code's purpose, describe all inputs and outputs, and provide examples. High level documentation must also be provided as guides, tutorials, and developer docs. Documentation must be provided in version control with the code and be made available online in a readable form.
9. **Testing**: Stable packages must provide unit tests of individual components (e.g. functions, classes) as well as integration tests that test the interaction between components that covers most of the code. Testing coverage should be measured. Automated testing is recommended, in which tests are run before any code is merged. System[link] and acceptance[link] testing are also recommended.
10. **Dependencies**: Projects should import the minimum number of packages necessary. Adding new dependencies should be a __considered__ decision.
11. **Python 3**: All packages must be compatible or work towards being compatible with Python 3. Providing ongoing support for Python 2 is not recommended as the end of life for Python 2 is January 1, 2020 (see [PEP 373](https://www.python.org/dev/peps/pep-0373/)).
12. **Duplication**: Duplication of code and functionality is discouraged. Forking projects into new projects is strongly discouraged.
13. **Collaboration**: Contributions to packages must be encouraged. Packages must provide contribution guidelines and clearly explain when a contribution is not accepted.
14. **Binaries**: Binary files should be added to the package repository only when necessary in order to keep packages as light as possible. Jupyter notebooks can be binary files and should not be committed to the package repository but can be provided in other repositories.
15. **Code of conduct**: Each project must adopt a code of conduct that is compatible with the [Contributor Covenant](https://www.contributor-covenant.org) and make it publicly available.