Run code linting tools with pre-commit hooks

Implements black formatting, end-of-file line fixing, trailing whitespace and yaml styling

Author: tennlee

.github/workflows/python-app.yml

@@ -45,7 +45,7 @@ jobs:
     steps:
     - name: Indicate Coveralls Parallel Finished
       uses: coverallsapp/github-action@v2.3.0
-      with: 
-        parallel-finished: true                
+      with:
+        parallel-finished: true
+
 
-  

.readthedocs.yaml

@@ -20,4 +20,4 @@ sphinx:
 # See https://docs.readthedocs.io/en/stable/guides/reproducible-builds.html
 python:
    install:
-   - requirements: requirements-docs.txt
+   - requirements: requirements-docs.txt

NOTICE.md

@@ -11,4 +11,3 @@ The file packages/utils/src/pyearthtools/utils/parsing/init_parsing.py contains
 The file packages/data/src/pyearthtools/data/indexes/utilities/folder_size.py contains code from https://stackoverflow.com/questions/1392413/calculating-a-directorys-size-using-python, released under Creative Commons BY-SA 4.0 (International).
 
 The file packages/data/src/edit/data/indexes/extensions.py extends and is largely sourced from https://github.com/pydata/xarray/blob/main/xarray/core/extensions.py, released under the Apache 2.0 license.
-

README.md

@@ -20,6 +20,5 @@ We have information for:
  - [Installation instructions](https://pyearthtools.readthedocs.io/en/latest/installation.html) for different usage scenarios
  - [Data catalogue setup](https://pyearthtools.readthedocs.io/en/latest/catalogue.html) for facility managers or individuals to establish their research data catalogue
  - [A shiny tutorial gallery full of neat examples](https://pyearthtools.readthedocs.io/en/latest/nbook/Gallery.html)
- - Much more, including how-to guides, project setup guide, information on accessing data, guides to evaluation, orientiation for 
+ - Much more, including how-to guides, project setup guide, information on accessing data, guides to evaluation, orientiation for
    physical scientists and data scientists at our [documentation homepage](https://pyearthtools.readthedocs.io/en/latest/) (you may be reading this now or you may be visiting the README from elsewhere)
-

docs/api.md

@@ -31,4 +31,4 @@
     :members:
 .. autofunction:: scores.categorical.seeps
 ```
- -->
+ -->

docs/catalogue.md

@@ -25,17 +25,17 @@ The good news is that even though there is no end to data volume increases, ther
 
 ## The role of data in science and machine learning
 
-Data is essential in three ways. 
+Data is essential in three ways.
 
-Firstly, access to open, trusted data sets is essential to being able to commence an academic research project into machine learning. Most researchers will get their start on data the can access easily. There are few things which have more impact than publishing high-quality open research benchmark datasets for stimulating research into a particular field or area. 
+Firstly, access to open, trusted data sets is essential to being able to commence an academic research project into machine learning. Most researchers will get their start on data the can access easily. There are few things which have more impact than publishing high-quality open research benchmark datasets for stimulating research into a particular field or area.
 
 Secondly, machine learning systems which are only trained on closed data sources are unlikely to be trusted by fellow researchers, leading to a lack of research interest in the field. Research thrives on re-use of prior research and prior data, inspiring people to investigate, compete and innovate. While not all data needs to be made public, providing enough to enable methodological research is important, particularly for validation and verification purposes.
 
-Thirdly, publishing research (or even operational/official) data from a new model allows others to evaluate, compare and assess the efficacy of models. 
+Thirdly, publishing research (or even operational/official) data from a new model allows others to evaluate, compare and assess the efficacy of models.
 
 ## Connecting directly to cloud data storage
 
-It is technically possible to access all data via a network, without involving a local on-disk cache. For model inference, this is reasonably efficient. For model training which required repeated access of the relevant data, using cloud storage directly is very inefficient. 
+It is technically possible to access all data via a network, without involving a local on-disk cache. For model inference, this is reasonably efficient. For model training which required repeated access of the relevant data, using cloud storage directly is very inefficient.
 
 ## Creating an on-disk catalogue
 
@@ -48,4 +48,4 @@ It is technically possible to access all data via a network, without involving a
 
 ## Separating project data from general open data
 
-## Creating new datasets for sharing and cataloguing
+## Creating new datasets for sharing and cataloguing

docs/devguide.md

@@ -31,13 +31,13 @@ Unless you are an advanced Git user, we would recommend you follow this process:
 
 Prior to developing a pull request, it may be a good idea to create a GitHub issue to capture what the pull request is trying to achieve, any pertinent details, and (if applicable) how it aligns to the roadmap. Otherwise, please explain this in the pull request.
 
-To submit a pull request, please use the following workflow: 
+To submit a pull request, please use the following workflow:
 
 1. Ensure you are working on a new feature branch in **your fork**.
 2. Keep your feature branch rebased and up-to-date with the develop branch of PyEarthTools. You can do this by first syncing the develop branch on your fork, and then rebase your feature branch against the develop branch on your fork.
 3. When ready, submit a pull request to the develop branch of https://github.com/ACCESS-Community-Hub/PyEarthTools.
 
-To help disambiguate branches, some contributors like to prefix their branch names with a short numerical indentifier. This is up to the contributor and any approach to branch naming is welcome. 
+To help disambiguate branches, some contributors like to prefix their branch names with a short numerical indentifier. This is up to the contributor and any approach to branch naming is welcome.
 
 ## Pull Request Etiquette
 
@@ -61,4 +61,4 @@ A code review is responsible for checking the following:
 4. Style guidelines are followed, static analysis and lint checking have been done
 5. Code is readable and well-structured
 6. Code does not do anything unexpected or beyond the scope of the function
-7. Any additional dependencies are justified and do not result in bloat
+7. Any additional dependencies are justified and do not result in bloat

docs/installation.md

@@ -74,7 +74,7 @@ Developers of PyEarthTools will most likely want to check out the entire monorep
 The following instructions detail how to install PyEarthTools in [editable mode](https://setuptools.pypa.io/en/latest/userguide/development_mode.html), making it easier to implement and test changes iteratively.
 
 ```{tip}
-Each sub-package is versioned separately, so bugfixes or updates in a single sub-package can be performed independently without requiring a new release of the entire ecosystem. 
+Each sub-package is versioned separately, so bugfixes or updates in a single sub-package can be performed independently without requiring a new release of the entire ecosystem.
 ```
 
 First clone the PyEarthTools repository:

docs/maintainer.md

@@ -13,11 +13,11 @@ Information relevant for package maintenance
 ## This section covers asking new contributors to add their details to .zenodo.json
 
 ```
-Thank you very much for your contribution. 
+Thank you very much for your contribution.
 
 When we release a new version of PyEarthTools, that version is archived on Zenodo. See: XXXXX
 
-As you have contributed to PyEarthtools, would you like to be listed on Zenodo as an author the next time PyEarthTools is archived? 
+As you have contributed to PyEarthtools, would you like to be listed on Zenodo as an author the next time PyEarthTools is archived?
 
 If so, please open a new pull request. In that pull request please add your details to .zenodo.json (which can be found in the PyEarthTools root directory).
 
@@ -34,15 +34,15 @@ tldr; about 3 years old is OK, longer if painless
 
 [https://scientific-python.org/specs/spec-0000/](https://scientific-python.org/specs/spec-0000/) provides a guide for the scientific Python ecosystem - we should aspire to be at least that compatible with older versions. It describes an approach including outlining when particular packages move out of support.
 
-We have not tested compatibility against all possible package versions which are included in this spec. Conversely, in some cases, it has been fairly straightforward to support packages older than this. 
+We have not tested compatibility against all possible package versions which are included in this spec. Conversely, in some cases, it has been fairly straightforward to support packages older than this.
 
 There is no formal "support" agreement for PyEarthTools. In the context of PyEarthTools package management, maintaining compability means being willing to make reasonable efforts to resolve any issues raised on the issue tracker. If a specific issue arises that would make it impractical to support a version within the compatibility window, then a response will be discussed and agreed on at the time on the basis of practicality.
 
-There is currently no specific testing for older versions of libraries, only older versions of Python (which may or may not intake an older library version). A full matrix test of Python and package versioning would be prohibitively complex, and there would also be no guarantee that pinned older versions wouldn't result in an insecure build (even if only in a test runner). 
+There is currently no specific testing for older versions of libraries, only older versions of Python (which may or may not intake an older library version). A full matrix test of Python and package versioning would be prohibitively complex, and there would also be no guarantee that pinned older versions wouldn't result in an insecure build (even if only in a test runner).
 
 The development branch versioning is unpinned, and so any issues arising from newly-released packages should quickly be encountered and then resolved before the next PyEarthTools release. Releases of PyEarthTools use "~=" versioning, which gives flexibility within a range of versions (see [https://packaging.python.org/en/latest/specifications/version-specifiers/#id5](https://packaging.python.org/en/latest/specifications/version-specifiers/#id5)).
 
-## This section covers how to build the documentation locally 
+## This section covers how to build the documentation locally
 (Readthedocs should update automatically from a GitHub Action)
 
 ### 1. Summary of the tech stack
@@ -89,11 +89,9 @@ Frequent issues include:
 
 ### Tutorial rendering
 
-Things that render well in JupyterLab do not always render properly in readthedocs. Additionally, fixes that work well when built locally, don't always work when merged into the codebase. 
+Things that render well in JupyterLab do not always render properly in readthedocs. Additionally, fixes that work well when built locally, don't always work when merged into the codebase.
 
 To check the rendering of tutorials in readthedocs:
   - Compare the tutorial in readthedocs against a version running in JupyterLab (as not everything renders in GitHub).
   - Check the entirety of the tutorial (sometimes things will render properly in one section, while not rendering properly in a different section of the same tutorial).
   - If you make any changes to the code cells, re-execute the Notebook in JupyterLab before committing, otherwise some things (e.g. some plots) won't render in readthedocs. Then re-check the tutorial in readthedocs to ensure the tutorial is still rendering properly.
-
-

docs/newuser.md

@@ -1,6 +1,6 @@
 # New Users Guide
 
-Welcome new user! This document will be continually updated based on new user experiences. 
+Welcome new user! This document will be continually updated based on new user experiences.
 
 Table of Contents:
 
@@ -12,7 +12,7 @@ Table of Contents:
 
 ## Introduction for Earth System Scientists
 
-PyEarthTools will greatly simplify your data access and data transformation code. 
+PyEarthTools will greatly simplify your data access and data transformation code.
 
 Machine learning models must first be 'trained'. All machine learning models, from simple examples like linear regression to complex multidimensional neural networks (which may require huge computational resources), are based on the same principles. Model input is drawn from the sample data and presented to the model. The model then makes a prediction. This prediction may be correct or incorrect. The prediction is compared to the desired output (sometimes called the target value or truth value). That comparison is scored using a loss function. That loss function is then used to update the model based on the accuracy of the prediction. Sometimes this is done in small batches (e.g. 8 samples at once). This process is called model training.
 
@@ -57,10 +57,10 @@ BRAN[doi] # Get BRAN data at doi
 > [!NOTE]
 > This section of the documentation is currently under development
 
-## Main Features of PyEarthTools for Model Inference	
+## Main Features of PyEarthTools for Model Inference
 
 > [!NOTE]
 > This section of the documentation is currently under development
 
 
-	
+