Pre-commit Update

.clang-format

@@ -34,7 +34,7 @@ AlwaysBreakBeforeMultilineStrings: false
 AlwaysBreakTemplateDeclarations: true
 BinPackArguments: true
 BinPackParameters: true
-BraceWrapping:   
+BraceWrapping:
   AfterClass:      false
   AfterControlStatement: false
   AfterEnum:       false
@@ -65,7 +65,7 @@ DisableFormat:   false
 ExperimentalAutoDetectBinPacking: false
 FixNamespaceComments: true
 ForEachMacros:   [ foreach, Q_FOREACH, BOOST_FOREACH ]
-IncludeCategories: 
+IncludeCategories:
   - Regex:           '^"'
     Priority:        1
   - Regex:           '^<'

.github/workflows/pull_request.yaml

@@ -24,7 +24,7 @@ jobs:
   check_formatting:
     uses: NWChemEx/.github/.github/workflows/check_formatting.yaml@master
     with:
-      license_config: ".github/.licenserc.yaml"
+      license_config: ".licenserc.yaml"
 
   test_nwx_docs:
     uses: NWChemEx/.github/.github/workflows/test_nwx_docs.yaml@master

.github/.licenserc.yaml → .licenserc.yaml

@@ -24,5 +24,6 @@ header:
     - cmake/generate_module_docs.cpp.in
     - LICENSE
     - version.txt
+    - build/
 
-  comment: never
+  comment: never

LICENSE

@@ -174,4 +174,4 @@
       incurred by, or claims asserted against, such Contributor by reason
       of your accepting any such warranty or additional liability.
 
-   END OF TERMS AND CONDITIONS
+   END OF TERMS AND CONDITIONS

docs/requirements.txt

@@ -1,4 +1,4 @@
 sphinx==v7.2.6
 sphinx_rtd_theme==1.3.0
-sphinxcontrib-bibtex
 sphinx_tabs
+sphinxcontrib-bibtex

docs/source/background/scientific_software.rst

@@ -145,7 +145,7 @@ software. With regards to why scientific software is unique:
 #. Performance
 
    - Scientific software is among the most computationally expensive software
-     in the world. The high computational complexity of many algorithms means 
+     in the world. The high computational complexity of many algorithms means
      that even a small degradation in performance can result in a simulation
      becoming intractable.
    - Often requires high-performance computing
@@ -158,7 +158,7 @@ software. With regards to why scientific software is unique:
      the scientists themselves.
    - Benefit to cost ratio of dependencies must be large, i.e., dependencies are
      usually only considered if they save a lot of time, or are very performant.
-     In addition, the scientists need to have some level of assurance that the 
+     In addition, the scientists need to have some level of assurance that the
      dependency will continue to be supported in the future.
    - Most scientists prefer to do as little software development as possible.
 
@@ -170,7 +170,7 @@ software. With regards to why scientific software is unique:
    - Users may come up with use cases beyond the scope of the original software.
    - Research leads to new quantities of interest, and software needs to be
      extensible to support these new properties.
-   - New algorithms for computing a property emerge. The software architecture 
+   - New algorithms for computing a property emerge. The software architecture
      needs to be able to use these algorithms throughout the code.
 
 #. Complex nature of scientific research
@@ -190,10 +190,10 @@ software. With regards to why scientific software is unique:
 
    - Developers are typically spread out across the world, making synchronization
      difficult.
-   - The scientific software community encapsulates an entire range of software 
-     engineering capabilities. Therefore, the quality of contributions and 
+   - The scientific software community encapsulates an entire range of software
+     engineering capabilities. Therefore, the quality of contributions and
      software products can vary widely.
-   - There is a need to protect unpublished research to ensure publication 
+   - There is a need to protect unpublished research to ensure publication
      rights. Decentralized development allows you to keep your unpublished
      research separate.
 

docs/source/conf.py

@@ -24,9 +24,9 @@
 
 # -- Project information -----------------------------------------------------
 
-project = u'PluginPlay'
-copyright = u'2020, NWChemEx Team'
-author = u'NWChemEx Team'
+project = "PluginPlay"
+copyright = "2020, NWChemEx Team"
+author = "NWChemEx Team"
 
 # Get the version from version.txt
 version = "1.0.0"
@@ -40,15 +40,20 @@
 # -- General configuration ---------------------------------------------------
 
 # We use numref which is introduced in Sphinx 1.3
-needs_sphinx = '1.3'
+needs_sphinx = "1.3"
 
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
 extensions = [
-    'sphinx.ext.autodoc', 'sphinx.ext.mathjax', 'sphinx.ext.githubpages',
-    'sphinx.ext.autosummary', 'sphinx_rtd_theme', 'sphinxcontrib.bibtex',
-    'sphinx.ext.githubpages', 'sphinx_tabs.tabs'
+    "sphinx.ext.autodoc",
+    "sphinx.ext.mathjax",
+    "sphinx.ext.githubpages",
+    "sphinx.ext.autosummary",
+    "sphinx_rtd_theme",
+    "sphinxcontrib.bibtex",
+    "sphinx.ext.githubpages",
+    "sphinx_tabs.tabs",
 ]
 dir_path = os.path.dirname(os.path.realpath(__file__))
 doc_path = os.path.dirname(dir_path)
@@ -58,25 +63,25 @@
 # You can specify multiple suffix as a list of string:
 #
 # source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
+source_suffix = ".rst"
 
 # The master toctree document.
-master_doc = 'index'
+master_doc = "index"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = 'en'
+language = "en"
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path .
 exclude_patterns = []
 
 # The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
+pygments_style = "sphinx"
 
 # Should figures be numbered?
 numfig = True
@@ -86,20 +91,20 @@
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'sphinx_rtd_theme'
+html_theme = "sphinx_rtd_theme"
 
 html_logo = "assets/full_logo.png"
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-html_theme_options = {'logo_only': True}
+html_theme_options = {"logo_only": True}
 
 # 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']
 
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.
@@ -114,23 +119,20 @@
 # -- Options for HTMLHelp output ---------------------------------------------
 
 # Output file base name for HTML help builder.
-htmlhelp_basename = project + 'doc'
+htmlhelp_basename = project + "doc"
 
 # -- Options for LaTeX output ------------------------------------------------
 
 latex_elements = {
     # The paper size ('letterpaper' or 'a4paper').
     #
     # 'papersize': 'letterpaper',
-
     # The font size ('10pt', '11pt' or '12pt').
     #
     # 'pointsize': '10pt',
-
     # Additional stuff for the LaTeX preamble.
     #
     # 'preamble': '',
-
     # Latex figure (float) alignment
     #
     # 'figure_align': 'htbp',
@@ -140,39 +142,53 @@
 # (source start file, target name, title,
 #  author, documentclass [howto, manual, or own class]).
 latex_documents = [
-    (master_doc, project + '.tex', project + ' Documentation', author,
-     'manual'),
+    (
+        master_doc,
+        project + ".tex",
+        project + " Documentation",
+        author,
+        "manual",
+    ),
 ]
 
 # -- Options for manual page output ------------------------------------------
 
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
-man_pages = [(master_doc, project.lower(), project + ' Documentation',
-              [author], 1)]
+man_pages = [
+    (master_doc, project.lower(), project + " Documentation", [author], 1)
+]
 
 # -- Options for Texinfo output ----------------------------------------------
 
 # Grouping the document tree into Texinfo files. List of tuples
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-    (master_doc, project, project + ' Documentation', author, project,
-     'One line description of project.', 'Miscellaneous'),
+    (
+        master_doc,
+        project,
+        project + " Documentation",
+        author,
+        project,
+        "One line description of project.",
+        "Miscellaneous",
+    ),
 ]
 
 # -- Extension configuration -------------------------------------------------
 
 # -- Options for intersphinx extension ---------------------------------------
 
 # Example configuration for intersphinx: refer to the Python standard library.
-intersphinx_mapping = {'https://docs.python.org/': None}
+intersphinx_mapping = {"https://docs.python.org/": None}
 
 # -- Options for bibtex --------------------------------------------------------
 
 bibtex_bibfiles = [
-    'bibliography/background.bib', 'bibliography/design.bib',
-    'bibliography/pluginplay.bib'
+    "bibliography/background.bib",
+    "bibliography/design.bib",
+    "bibliography/pluginplay.bib",
 ]
-bibtex_reference_style = 'super'
-bibtex_default_style = 'plain'
+bibtex_reference_style = "super"
+bibtex_default_style = "plain"

docs/source/developer/design/field.rst

@@ -18,14 +18,14 @@
 Designing the Field Component
 #############################
 
-:ref:`property_type_design` and :ref:`module_design` both called for a 
+:ref:`property_type_design` and :ref:`module_design` both called for a
 mechanism to handle fields.
 
 ****************************
 What is the Field Component?
 ****************************
 
-Modules are meant to be black-box functions which take all the input (inputs 
+Modules are meant to be black-box functions which take all the input (inputs
 and callbacks) they will need to compute their results. The inputs and
 results are the fields. Since callbacks are passed as inputs we consider how
 they are passed to be part of the field component, while the actual callback
@@ -55,7 +55,7 @@ Field Component Considerations
    - Associating checks with the field avoids waiting until the module runs to
      ensure the field's value is valid.
    - Used to prevent users from setting a field to an incorrect value (before
-     the module tries to unwrap the input). 
+     the module tries to unwrap the input).
 
 #. Leverage metadata to generate documentation.
 
@@ -77,13 +77,13 @@ Field Component Design
    to/from a module and SubmoduleRequest is used to manage callback hooks.
 
 :numref:`fig_field_design` shows the architecture of the field component.
-The three major components, ``ModuleInput``, ``ModuleResult``, and 
+The three major components, ``ModuleInput``, ``ModuleResult``, and
 ``SubmoduleRequest`` correspond to three major items passed into/from modules.
 ``ModuleInput``  manages an input to a module (the set of inputs passed to a
 module will be a container of ``ModuleInput`` objects). In addition to the
 type-erased input, which lives in the ``AnyField`` object, the ``ModuleInput``
 also holds metadata (*e.g.*, a description, if the user set the value, is
-the value :ref:`opaque`) and any bounds checks (*e.g.*, can the value be null, 
+the value :ref:`opaque`) and any bounds checks (*e.g.*, can the value be null,
 is there a maximum/minimum for the value, what are the allowed strings). The
 ``ModuleResult`` is similar except it does not have bounds checks (the
 module developer presumably is not trying to return invalid results). The
@@ -117,4 +117,4 @@ Summary
 #. Leverage metadata to generate documentation.
 
    - Not strictly part of the field component, but the field component exposes
-     enough information for another component to generate the documentation.
+     enough information for another component to generate the documentation.

docs/source/developer/design/property_type.rst

@@ -28,7 +28,7 @@ What is the Property Type Component?
 At the lowest level all modules have the same :ref:`api`: take a series of
 type-erased inputs and return a set of type-erased outputs. In strongly typed
 languages like C++, type-erased objects are cumbersome to work with. The
-property type component facilitates the wrapping/unwrapping of 
+property type component facilitates the wrapping/unwrapping of
 typed/type-erased objects while also enforcing a standardized :ref:`api`.
 
 ****************************
@@ -62,7 +62,7 @@ While not explicitly called for at this point we also want:
 
    - Many properties are related via "is-a-type-of" relationships.
    - Inheritance captures "is-a-type-of" relationships and can be used for
-     avoiding duplication 
+     avoiding duplication
 
 ******************************
 Property Type Component Design
@@ -81,7 +81,7 @@ Property Type Component Design
 Fig :numref:`fig_property_type_design` shows the architecture of the property
 type component. The ``PropertyType`` class holds the bulk of the implementation.
 Users derive their property types from ``PropertyType``, using the curiously-
-recursive template pattern (CRTP). CRTP facilitates PluginPlay implementing 
+recursive template pattern (CRTP). CRTP facilitates PluginPlay implementing
 features on behalf of the user, without PluginPlay knowing the types. *N.B.*,
 normal inheritance would not allow the ``PropertyType`` class to access the
 types defined in the derived class. In our implementation ``PropertyType`` is
@@ -91,7 +91,7 @@ will implement four functions ``wrap_inputs``, ``wrap_results``,
 un-type-erase data on behalf of the user.
 
 In the derived class, users fill in two ``FieldTuple`` objects, one for the
-inputs and one for the results. The process of doing this is wrapped by 
+inputs and one for the results. The process of doing this is wrapped by
 "virtual" functions (since we're using CRTP they're not actually virtual)
 ``inputs_`` and ``results_`` respectively. The ``FieldTuple`` objects are
 responsible for storing not only the types of the inputs, but also the default
@@ -105,19 +105,19 @@ Our design addresses the above considerations by:
 
 #. Dynamic determine module :ref:`api`
 
-   - ``unwrap_inputs`` / ``unwrap_results`` and 
-     ``wrap_inputs`` / ``wrap_results`` functions can be used at runtime to go 
+   - ``unwrap_inputs`` / ``unwrap_results`` and
+     ``wrap_inputs`` / ``wrap_results`` functions can be used at runtime to go
      from/to type-erased inputs/results.
 
 #. Domain agnostic
 
    - CRTP allows the ``PropertyType`` class to access derived class's types
      through "inheritance".
-   - Derived classes, and their types, live in downstream code. 
+   - Derived classes, and their types, live in downstream code.
 
 #. Avoid exposing templates to the user (to the extent possible)
 
-   - Largely falls to ``FieldTuple`` component. 
+   - Largely falls to ``FieldTuple`` component.
    - Macros further de-template the :ref:`api`.
 
 #. Use property types to factor out input/result provenance
@@ -128,4 +128,3 @@ Our design addresses the above considerations by:
 #. Allow property type inheritance
 
    - ``PropertyType`` is templated on base property types.
-