add breadcrumb and pre-commit

.flake8

@@ -0,0 +1,7 @@
+[flake8]
+exclude = build, doc/source/conf.py
+select = W191, W291, W293, W391, E115, E117, E122, E124, E125, E225, E231, E301, E303, E501, F401, F403
+count = True
+max-complexity = 10
+max-line-length = 100
+statistics = True

.github/workflows/ci-build.yml

@@ -9,6 +9,24 @@ on:
       - main
 
 jobs:
+  pre-commit:
+    name: Pre-commit checks
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: 3.7
+      - name: Install pre-commit requirements
+        run: |
+          pip install pre-commit~=2.16.0
+
+      - name: Run pre-commit
+        run: |
+          pre-commit run --all-files || ( git status --short ; git diff ; exit 1 )
+
   docs_build:
     runs-on: ubuntu-latest
 
@@ -26,6 +44,16 @@ jobs:
           make -C doc html SPHINXOPTS="-W"
           touch doc/build/html/.nojekyll
           echo "dev.docs.pyansys.com" > doc/build/html/CNAME
+
+      - name: Deploy to gh-pages on main
+        if: github.ref == 'refs/heads/main'
+        uses: JamesIves/[email protected]
+        with:
+          token: ${{ secrets.github_token }}
+          branch: gh-pages
+          folder: docs/build/html
+          clean: true
+          single-commit: true
 
       - name: Build PDF Documentation
         run: |
@@ -64,17 +92,9 @@ jobs:
       - name: Display structure of downloaded files
         run: ls -R
 
-      - name: Deploy to gh-pages
-        uses: JamesIves/[email protected]
-        with:
-          token: ${{ secrets.github_token }}
-          branch: gh-pages
-          folder: HTML-Documentation
-          clean: true
-          single-commit: true
-
       - name: Release
         uses: softprops/action-gh-release@v1
         with:
+          generate_release_notes: true
           files: |
             ./*PDF*/*.pdf

.pre-commit-config.yaml

@@ -0,0 +1,28 @@
+repos:
+- repo: https://github.com/psf/black
+  rev: 21.12b0
+  hooks:
+  - id: black
+    exclude: "^({{cookiecutter.project_slug}}/)"
+- repo: https://github.com/asottile/reorder_python_imports
+  rev: v2.6.0
+  hooks:
+  - id: reorder-python-imports
+    args: ["--py37-plus"]
+    exclude: "^({{cookiecutter.project_slug}}/)"
+- repo: https://gitlab.com/PyCQA/flake8
+  rev: 3.9.2
+  hooks:
+  - id: flake8
+    exclude: "^({{cookiecutter.project_slug}}/)"
+- repo: https://github.com/codespell-project/codespell
+  rev: v2.1.0
+  hooks:
+  - id: codespell
+    args: [--ignore-words=ignore_words.txt, -S \*.pyc\,\*.xml\,\*.txt\,\*.gif\,\*.png\,\*.jpg\,\*.js\,\*.html\,\*.doctree\,\*.ttf\,\*.woff\,\*.woff2\,\*.eot\,\*.mp4\,\*.inv\,\*.pickle\,\*.ipynb\,flycheck\*\,./.git/\*\,./.hypothesis/\*\,\*.yml\,./doc/build/\*\,./doc/images/\*\,./dist/\*\,\*~\,.hypothesis\*\,./doc/source/examples/\*\,\*cover\,\*.dat\,\*.mac]
+# - repo: https://github.com/pycqa/pydocstyle
+#   rev: 6.1.1
+#   hooks:
+#   - id: pydocstyle
+#     additional_dependencies: [toml]
+#     exclude: "^({{cookiecutter.project_slug}}/)"

doc/source/conf.py

@@ -1,30 +1,31 @@
 from datetime import datetime
 
-from pyansys_sphinx_theme import __version__, pyansys_logo_black
+from pyansys_sphinx_theme import __version__
+from pyansys_sphinx_theme import pyansys_logo_black
 
 # Project information
-project = 'PyAnsys Developers Guide'
+project = "PyAnsys Developers Guide"
 copyright = f"(c) {datetime.now().year} ANSYS, Inc. All rights reserved"
 author = "Ansys Inc."
-release = version = '0.2.dev0'
+release = version = "0.2.dev0"
 
 html_logo = pyansys_logo_black
-html_theme = 'pyansys_sphinx_theme'
+html_theme = "pyansys_sphinx_theme"
 
 html_theme_options = {
     "github_url": "https://github.com/pyansys/about",
-    "show_prev_next": False
+    "show_prev_next": False,
 }
 
 # Sphinx extensions
 extensions = [
     "sphinx_copybutton",
-    'sphinx_toolbox.collapse',
-    'sphinx.ext.autodoc',
-    'sphinx.ext.autosummary',
-    'sphinx.ext.intersphinx',
-    'sphinx.ext.napoleon',
-    'sphinx.ext.todo',
+    "sphinx_toolbox.collapse",
+    "sphinx.ext.autodoc",
+    "sphinx.ext.autosummary",
+    "sphinx.ext.intersphinx",
+    "sphinx.ext.napoleon",
+    "sphinx.ext.todo",
 ]
 
 # Intersphinx mapping
@@ -38,22 +39,24 @@
 }
 
 # The suffix(es) of source filenames.
-source_suffix = '.rst'
+source_suffix = ".rst"
 
 # The master toctree document.
-master_doc = 'index'
+master_doc = "index"
 
 latex_elements = {}
 
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title,
 #  author, documentclass [howto, manual, or own class]).
 latex_documents = [
-    (master_doc,
-     f'pyansys_dev_guide_v{version}.tex',
-     "PyAnsys Developer's Guide",
-     author,
-     'manual'),
+    (
+        master_doc,
+        f"pyansys_dev_guide_v{version}.tex",
+        "PyAnsys Developer's Guide",
+        author,
+        "manual",
+    ),
 ]
 
 

doc/source/documentation_style/sample_func.py

@@ -1,14 +1,14 @@
 def func(arg1, arg2):
     """Summary line <should be only one line>.
 
-    Extended description of the function. The extended description, 
-    which can span multiple lines, should provide a general overview 
+    Extended description of the function. The extended description,
+    which can span multiple lines, should provide a general overview
     of the function.
 
     .. warning::
        Use the ``.. warning::`` directive within the docstring for any
-       warnings that need to be explicitly stated. For example, you 
-       want to include a warning for a method that is to be deprecated 
+       warnings that need to be explicitly stated. For example, you
+       want to include a warning for a method that is to be deprecated
        in the next release.
 
     Parameters

doc/source/guidelines/dev_practices.rst

@@ -3,7 +3,7 @@
 Development Practices
 =====================
 This page explains how PyAnsys development is conducted. When
-contributing to a PyAnsys repository, use these general 
+contributing to a PyAnsys repository, use these general
 coding paradigms:
 
 #. Follow the `Zen of Python <https://www.python.org/dev/peps/pep-0020/>`__.
@@ -35,15 +35,15 @@ To submit new code to a PyAnsys repository:
 
 #. `Fork <https://docs.github.com/en/get-started/quickstart/fork-a-repo>`_
    the respective GitHub repository and then clone the forked repository
-   to your computer. 
+   to your computer.
 
 #. In your local repository, create a branch. See :ref:`branch_naming`.
-   Comprehensive information on our model for branching is availible in
+   Comprehensive information on our model for branching is available in
    `Branching Model <#Branching Model>`__.
 
 #. Add your new feature and commit it locally. Be sure to commit
    frequently as the ability to revert to past commits is often helpful,
-   especially if your change is complex. 
+   especially if your change is complex.
 
 #. Test often. See `Testing <#Testing>`__ for automating testing.
 
@@ -104,11 +104,11 @@ any new issues from your changes.
 
 .. code::
 
-    pytest -v --cov _unittest
+    pytest -v --cov <ansys.product.library>
 
 Error Messages
 ~~~~~~~~~~~~~~
-For general information on writting good error messages, see Microsoft's
+For general information on writing good error messages, see Microsoft's
 `Error Message Guidelines <https://docs.microsoft.com/en-us/windows/win32/debug/error-message-guidelines>`_.
 
 For information specific to writing Pythonic error messages, see:
@@ -130,7 +130,7 @@ If you are using Linux or Mac OS, run spelling and coding style checks:
 
 Misspelled words will be reported. You can add words to be ignored to
 the ``ignore_words.txt`` file. For example, for PyMAPDL, this file looks
-like this: 
+like this:
 
 ... code::
 
@@ -173,7 +173,7 @@ tasks:
 Branching Model
 ---------------
 The branching model for a PyAnsys project enables rapid development of
-features without sacrificing stability. The model closely follows the 
+features without sacrificing stability. The model closely follows the
 `Trunk Based Development <https://trunkbaseddevelopment.com/>`_ approach:
 
 - The `main` branch is the primary development branch. All features,
@@ -216,7 +216,7 @@ Release procedures follow for major and minor releases.
 
 #. Locally test and build the documentation with link checking to
    ensure that no links are outdated.
-   
+
 #. Run ``make clean`` to ensure that no results are cached.
 
     .. code::
@@ -233,10 +233,10 @@ Release procedures follow for major and minor releases.
    for this release that merges it to ``main``. While effort is focused
    on the release, development to ``main`` should be limited.
 
-#. Wait for the PyAnsys developers and community to functionally test the
-   new release. Testors should locally install this branch and use it in
-   production. Any bugs that they identify should have their hotfixes pushed to
-   this release branch.
+#. Wait for the PyAnsys developers and community to functionally test the new
+   release. Developers and testers should locally install this branch and use
+   it in production. Any bugs that they identify should have their hotfixes
+   pushed to this release branch.
 
    When the branch is deemed as stable for public release, the PR is merged
    to ``main``, which must then be tagged with a ``MAJOR.MINOR.0`` release.
@@ -246,7 +246,7 @@ Release procedures follow for major and minor releases.
 
     .. code::
 
-	     git tag v<MAJOR.MINOR.0>
+        git tag v<MAJOR.MINOR.0>
         git push origin --tags
 
 #. Create a list of all changes for the release. It is often helpful
@@ -256,7 +256,7 @@ Release procedures follow for major and minor releases.
    appropriate if specific contributors are to be thanked for new
    features.
 
-#. Place your release notes from the previous step in ``Releases`` 
+#. Place your release notes from the previous step in ``Releases``
    in the GitHub repository. See `GitHub Releases`_.
 
 .. _GitHub Releases: https://docs.github.com/en/github/administering-a-repository/releasing-projects-on-github/managing-releases-in-a-repository
@@ -272,7 +272,7 @@ should not wait until a minor release. These are the steps for a patch release:
    This will generally be the latest release branch (for example,
    ``release/MAJOR.MINOR``).
 
-#. Update the ``__version__.py`` file with the next patch increment
+#. Update the ``_version.py`` file with the next patch increment
    (``MAJOR.MINOR.PATCH``), commit it, and open a PR to merge with the
    release branch. This gives the PyAnsys developers and community
    an opportunity to validate and approve the bug fix release. Any