Add: precommit hooks and clean up all files

.circleci/config.yml

@@ -12,7 +12,7 @@ jobs:
             pip install nox
             pip list
       - run:
-          name: Build book html 
+          name: Build book html
           command: nox -s docs
 
       - store_artifacts:

.github/workflows/build-book.yml

@@ -1,7 +1,7 @@
 name: build-test-deploy-book
 
 # Only build PRs, the main branch, and releases. Pushes to branches will only
-# be built when a PR is opened. This avoids duplicated buids in PRs comming
+# be built when a PR is opened. This avoids duplicated buids in PRs coming
 # from branches in the origin repository (1 for PR and 1 for push).
 # This came from Leo's work with fatiando
 on:
@@ -53,7 +53,7 @@ jobs:
           _build/html/
 
     # Push the book's HTML to github-pages
-    - name: Push to GitHub Pages 
+    - name: Push to GitHub Pages
       # Only push if on main branch
       if: github.ref == 'refs/heads/main'
       uses: peaceiris/[email protected]
@@ -69,5 +69,3 @@ jobs:
         arguments: |
           --ignore-files "/.+\/_static\/.+/,/genindex.html/"
           --ignore-status-codes "404, 403, 503"
-
-

.pre-commit-config.yaml

@@ -0,0 +1,41 @@
+# pre-commit is a tool that you run locally
+# to perform a predefined set of tasks manually and/or
+# automatically before git commits are made.
+# Here we are using pre-commit with the precommit.ci bot to implement
+# code fixes automagically in pr's. You will still want to install pre-commit
+# to run locally
+# Config reference: https://pre-commit.com/#pre-commit-configyaml---top-level
+# To run on a pr, add a comment with the text "pre-commit.ci run"
+# Common tasks
+#
+# - Run on all files:   pre-commit run --all-files
+# - Register git hooks: pre-commit install --install-hooks
+
+ci:
+    autofix_prs: false
+    #skip: [flake8, end-of-file-fixer]
+    autofix_commit_msg: |
+        '[pre-commit.ci 🤖] Apply code format tools to PR'
+    # Update hook versions every quarter (so we don't get hit with weekly update pr's)
+    autoupdate_schedule: quarterly
+
+repos:
+
+  # Misc commit checks
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    # ref: https://github.com/pre-commit/pre-commit-hooks#hooks-available
+    hooks:
+      # Autoformat: Makes sure files end in a newline and only a newline.
+      - id: end-of-file-fixer
+      # Lint: Check for files with names that would conflict on a
+      # case-insensitive filesystem like MacOS HFS+ or Windows FAT.
+      - id: check-case-conflict
+      - id: trailing-whitespace
+
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.2.2
+    hooks:
+    - id: codespell
+      additional_dependencies:
+        - tomli

CONTRIBUTING.md

@@ -1,25 +1,25 @@
-# Contributing Guide for the Python open source software packaging book 
+# Contributing Guide for the Python open source software packaging book
 
 This is a community resource. We welcome contributions in the form of issues and/or pull requests to this guide.
 
-* If you have an idea for something that should be included in the guide, [please open an issue here](https://github.com/pyOpenSci/python-package-guide/issues). 
-* If you find a typo, feel free to [submit a pull request](https://github.com/pyOpenSci/python-package-guide/pulls) to modify the text directly. Or, if you are less comfortable with pull requests, feel free to open an issue. 
-* If you want to see a larger change to the content of the guide book, please submit an issue first! 
+* If you have an idea for something that should be included in the guide, [please open an issue here](https://github.com/pyOpenSci/python-package-guide/issues).
+* If you find a typo, feel free to [submit a pull request](https://github.com/pyOpenSci/python-package-guide/pulls) to modify the text directly. Or, if you are less comfortable with pull requests, feel free to open an issue.
+* If you want to see a larger change to the content of the guide book, please submit an issue first!
 
 ## How this guide structured
 
 Most of this repository is structured for **Sphinx**, a documentation engine built in `Python`. We are using the Sphinx Book Theme and the `myST` syntax to create each page in this book.
 
-If you wish to contribute by working on the guide book locally, you 
-will first need to 
+If you wish to contribute by working on the guide book locally, you
+will first need to
 
-1. Fork this repository 
+1. Fork this repository
 2. Clone it locally
-3. Build the documentation locally 
+3. Build the documentation locally
 
 ## Instructions for building the documentation locally on your computer
 
-The easiest way to build the documentation in this repository is to use `nox`, 
+The easiest way to build the documentation in this repository is to use `nox`,
 a tool for quickly building environments and running commands within them.
 Nox ensures that your environment has all the dependencies needed to build the documentation.
 

README.md

@@ -15,11 +15,11 @@ pyOpenSci is devoted to building diverse, supportive community around
 the Python open source tools that drive open science. We do this through:
 
 * open peer review
-* mentorship and 
+* mentorship and
 * training.
 
-pyOpenSci is an independent organization, fiscally sponsored by Community 
-Initiatives.  
+pyOpenSci is an independent organization, fiscally sponsored by Community
+Initiatives.
 
 :construction: Construction note :construction:
 
@@ -97,4 +97,4 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d
 
 <!-- ALL-CONTRIBUTORS-LIST:END -->
 
-This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!
+This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!

_static/pyos.css

@@ -41,4 +41,4 @@ figcaption {
 .admonition p {
     font-size: 1.1em;
     font-weight: bold;
-  }
+  }

_templates/header.html

@@ -3,5 +3,4 @@
 <!-- <link rel="preconnect" href="https://fonts.googleapis.com">
 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
 <link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;600&family=Raleway:wght@200;300;400;600&display=swap" rel="stylesheet">  -->
-<!-- END custom head content --> 
-
+<!-- END custom head content -->

ci-and-testing/intro.md

@@ -4,4 +4,4 @@
 This section is evolving and should be published by the end of Spring 2023
 
 
-coming soon
+coming soon

code-style-structure/intro.md

@@ -1,4 +1,4 @@
 # Code style and structure
 
 
-Under development
+Under development

codespell-ignore.txt

@@ -0,0 +1 @@
+aways

conf.py

@@ -74,11 +74,11 @@
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path.
 exclude_patterns = [
-    "_build", 
-    "Thumbs.db", 
-    ".DS_Store", 
-    ".github", 
-    ".nox", 
+    "_build",
+    "Thumbs.db",
+    ".DS_Store",
+    ".github",
+    ".nox",
     "README.md"
     ]
 
@@ -99,4 +99,4 @@
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+html_static_path = ['_static']

documentation/hosting-tools/intro.md

@@ -1,17 +1,17 @@
-# Tools to Build and Host your Documentation 
+# Tools to Build and Host your Documentation
 
-The most common tool for building documentation in the Python 
-ecosystem currently is Sphinx. However, some maintainers 
-are using tools like [mkdocs](https://www.mkdocs.org/) for documentation. It is 
+The most common tool for building documentation in the Python
+ecosystem currently is Sphinx. However, some maintainers
+are using tools like [mkdocs](https://www.mkdocs.org/) for documentation. It is
 up to you to use the platform that you prefer for your documentation!
 
-In this section, we introduce Sphinx as a common tool to 
-build documentation. We talk about various syntax options that you can use 
+In this section, we introduce Sphinx as a common tool to
+build documentation. We talk about various syntax options that you can use
 when writing Sphinx documentation including mySt and rST.
 
-We also talk about ways to publish your 
-documentation online and Sphinx tools that might help you optimize 
-your documentation website. 
+We also talk about ways to publish your
+documentation online and Sphinx tools that might help you optimize
+your documentation website.
 
 ## Documentation build tools outline
 

documentation/hosting-tools/myst-markdown-rst-doc-syntax.md

@@ -1,29 +1,29 @@
-# Documentation syntax: markdown vs. myST vs. rst syntax to create your docs 
+# Documentation syntax: markdown vs. myST vs. rst syntax to create your docs
 
 There are three commonly used syntaxes for creating Python documentation:
-1. [markdown](https://www.markdownguide.org/): Markdown is an easy-to-learn text 
-syntax. It is the default syntax use in Jupyter Notebooks. There are tools that you can add to a Sphinx website that allow it to render markdown as html. However, using markdown to write documentation has limitations. For instance if you want to add references, 
-colored call out blocks and other custom elements to your documentation, you will 
+1. [markdown](https://www.markdownguide.org/): Markdown is an easy-to-learn text
+syntax. It is the default syntax use in Jupyter Notebooks. There are tools that you can add to a Sphinx website that allow it to render markdown as html. However, using markdown to write documentation has limitations. For instance if you want to add references,
+colored call out blocks and other custom elements to your documentation, you will
 need to use either **myST** or **rST**.
 1. [rST (ReStructured Text):](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html). **rST** is the native syntax that sphinx supports. rST was the default syntax used for documentation for many years. However, in recent years myST has risen to the top as a favorite for documentation given the flexibility that it allows.
-1. [myST:](https://myst-parser.readthedocs.io/en/latest/intro.html) myST is a combination of vanilla of `markdown` and `rST` syntax. It is a nice option if you are comfortable writing markdown. `myst` is preferred by many because it offers both the rich functionality 
-of rST combined with a simple-to-write markdown syntax. 
+1. [myST:](https://myst-parser.readthedocs.io/en/latest/intro.html) myST is a combination of vanilla of `markdown` and `rST` syntax. It is a nice option if you are comfortable writing markdown. `myst` is preferred by many because it offers both the rich functionality
+of rST combined with a simple-to-write markdown syntax.
 
-While you can chose to use any of the syntaxes listed above, we suggest using 
+While you can chose to use any of the syntaxes listed above, we suggest using
 `myST` because:
 
 * It is a simpler syntax and thus easier to learn;
-* The above simplicity will make it easier for more people to contribute to your documentation. 
+* The above simplicity will make it easier for more people to contribute to your documentation.
 * Most of your corePythonpackage text files, such as your README.md file, are already in `.md` format
-* `GitHub` and `Jupyter Notebooks` support markdown thus it's more widely used in the scientific ecosystem. 
+* `GitHub` and `Jupyter Notebooks` support markdown thus it's more widely used in the scientific ecosystem.
 
 
 ```{tip}
-If you are on the fence about myST vs rst, you might find that **myST** is easier 
-for more people to contribute to.  
+If you are on the fence about myST vs rst, you might find that **myST** is easier
+for more people to contribute to.
 ```
 
-<!-- TODO 
-- add some text examples of using rst vs md vs myst? 
+<!-- TODO
+- add some text examples of using rst vs md vs myst?
 - Better explain what rst / myst offer that markdown can't do
 -->

documentation/hosting-tools/publish-documentation-online.md

@@ -1,44 +1,43 @@
 # How to publish your Python package documentation online
 
-We suggest that you setup a hosting service for your Python package 
+We suggest that you setup a hosting service for your Python package
 documentation. Two free and commonly used ways to
-quickly create a documentation website hosting environment are below. 
+quickly create a documentation website hosting environment are below.
 
-1. You can host your documentation yourself using [GitHub Pages](https://pages.github.com/) or another online hosting service. 
+1. You can host your documentation yourself using [GitHub Pages](https://pages.github.com/) or another online hosting service.
 1. You can host your documentation using [Read the Docs](https://readthedocs.org/).
 
 ## What is Read the Docs ?
-[Read the Docs](https://readthedocs.org/) is a documentation hosting service that supports publishing your project's documentation. 
+[Read the Docs](https://readthedocs.org/) is a documentation hosting service that supports publishing your project's documentation.
 
-Read the Docs is a fully featured, free, documentation hosting 
+Read the Docs is a fully featured, free, documentation hosting
 service. Some of its many features include:
 
 * Is free to host your documentation (but there are also paid tiers if you wish to customize hosting)
-* Automates building your documentation 
+* Automates building your documentation
 * Allows you to turn on integration with pull requests where you can view documentation build progress (success vs failure).
-* Supports versioning of your documentation which allows users to refer to older tagged versions of the docs if they are using older versions of your package. 
-* Supports downloading of documentation in PDF and other formats. 
-* You can customize the documentation build using a **.readthedocs.yaml** file in your GitHub repository. 
+* Supports versioning of your documentation which allows users to refer to older tagged versions of the docs if they are using older versions of your package.
+* Supports downloading of documentation in PDF and other formats.
+* You can customize the documentation build using a **.readthedocs.yaml** file in your GitHub repository.
 
 
 ## What is GitHub Pages?
-[GitHub Pages](https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages) is a free web 
-hosting service offered by GitHub. Using GitHub pages, you can build your 
-documentation locally or using a Continuous Integration setup, and then push 
-to a branch in your GitHub repository that is setup to run the GitHub Pages 
-web build.  
+[GitHub Pages](https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages) is a free web
+hosting service offered by GitHub. Using GitHub pages, you can build your
+documentation locally or using a Continuous Integration setup, and then push
+to a branch in your GitHub repository that is setup to run the GitHub Pages
+web build.
 
 
 
-## Read the Docs vs GitHub Pages 
+## Read the Docs vs GitHub Pages
 
-GitHub pages is a great option for your documentation deployment. 
-However, you will need to do a bit more work to build and deploy your 
-documentation if you use GitHub pages. 
+GitHub pages is a great option for your documentation deployment.
+However, you will need to do a bit more work to build and deploy your
+documentation if you use GitHub pages.
 
-Read the Docs can be setup in your Read the Docs user account. The service 
-and automates the entire process of building and deploying your documentation. 
+Read the Docs can be setup in your Read the Docs user account. The service
+and automates the entire process of building and deploying your documentation.
 
-If you don't want to maintain a documentation website for your Python package, 
+If you don't want to maintain a documentation website for your Python package,
 we suggest using the Read the Docs website.
-