Add references to MCNP user manual and documentation updates

.github/workflows/main.yml

@@ -120,6 +120,10 @@ jobs:
         run: | 
              cd doc/source
              python _test_for_missing_docs.py  
+      - name: Test for broken hyperlinks
+        run: |
+             cd doc
+             make linkcheck || true
 
   format-test:
     runs-on: ubuntu-latest

.gitignore

@@ -1,5 +1,6 @@
 __pycache__/
 build/*
+doc/build
 dist/*
 *egg-info/*
 *.mcnp

README.md

@@ -64,16 +64,5 @@ If you want to add a feature on your own talk to Micah Gale (but still add the i
 The system is very modular and you should be able to develop it pretty quickly.
 Also read the [developer's guide](https://idaholab.github.io/MontePy/developing.html).
 
-# Version Numbering Scheme
-
-* Software on `develop` and feature branches are subject to change without a version number increment. These version
-  may be suffixed as dev (e.g., `0.1.0.dev2`) and may change as features and bug fixes are implemented.
-
-* Versions are official if and only if they are:
-   1. on the branch `main`.
-   1. has a release git tag assigned
-   1. has distribution packages created and released
-   Official shall not change. New merges to main shall have a version number incremented.
-
 
 # Finally: make objects not regexes!

doc/source/_test_for_missing_docs.py

@@ -3,7 +3,13 @@
 import sys
 import warnings
 
-ignored = {"__pycache__", "_scripts", "_version.py", "__main__.py", "_cell_data_control.py"}
+ignored = {
+    "__pycache__",
+    "_scripts",
+    "_version.py",
+    "__main__.py",
+    "_cell_data_control.py",
+}
 
 base = os.path.join("..", "..")
 

doc/source/changelog.rst

@@ -8,20 +8,21 @@ MontePy Changelog
 
 **Documentation**
 
-* Added link to the PyPI project on the Sphinx site (#410)
+* Added link to the PyPI project on the Sphinx site (:issue:`410`)
+* Added link shortcuts for MCNP manual, and github issues and pull requests (:pull:`417`).
 
 **CI/CD**
 
-* Fixed project metadata for author to show up correctly on PyPI (#408)
+* Fixed project metadata for author to show up correctly on PyPI (:pull:`408`)
 
 0.2.7
 -----------------------
 
 **Bug fixes**
 
-* Made versioning system more robust for all situations (#386).
-* Fixed bug with handling `read` inputs, and made parser more efficient (#206)
-* Fixed bug that couldn't read materials without a library. E.g., `1001` vs. `1001.80c` (#365). 
+* Made versioning system more robust for all situations (:issue:`386`).
+* Fixed bug with handling `read` inputs, and made parser more efficient (:issue:`206`)
+* Fixed bug that couldn't read materials without a library. E.g., `1001` vs. `1001.80c` (:issue:`365`). 
 
 **Documentation**
 
@@ -32,7 +33,7 @@ MontePy Changelog
 **CI/CD**
 
 * Improved coveralls integration so actual source code can be shown.
-* Improved sphinx build process (#388)
+* Improved sphinx build process (:issue:`388`)
 
 
 0.2.5
@@ -67,11 +68,11 @@ MontePy Changelog
 
 **Changed**
 
-* Explicitly set file encoding for read/write. #159.
+* Explicitly set file encoding for read/write. :issue:`159`.
 
 **Fixed**
 
-* Bug with not detecting comments with no space e.g., `c\n`. #158.
+* Bug with not detecting comments with no space e.g., `c\n`. :issue:`158`.
 
 0.2.2
 --------------------

doc/source/conf.py

@@ -47,14 +47,24 @@
 # This pattern also affects html_static_path and html_extra_path.
 exclude_patterns = []
 
-wheel = f"montepy-{release}-py3-none-any.whl"
-
 # -- External link configuration ---------------------------------------------
-UM63 = "https://mcnp.lanl.gov/pdf_files/TechReport_2022_LANL_LA-UR-22-30006" \
-       "Rev.1_KuleszaAdamsEtAl.pdf"
+UM63 = (
+    "https://mcnp.lanl.gov/pdf_files/TechReport_2022_LANL_LA-UR-22-30006"
+    "Rev.1_KuleszaAdamsEtAl.pdf"
+)
+UM62 = (
+    "https://mcnp.lanl.gov/pdf_files/TechReport_2017_LANL_LA-UR-17-29981"
+    "_WernerArmstrongEtAl.pdf"
+)
 extlinks = {
     # MCNP 6.3 User's Manual
-    "manual63" : (UM63 + "#subsection.%s", "%s"),
+    "manual63sec": (UM63 + "#section.%s", "MCNP 6.3 manual § %s"),
+    "manual63": (UM63 + "#subsection.%s", "MCNP 6.3 manual § %s"),
+    "manual63part": (UM63 + "#part.%s", "MCNP 6.3 manual § %s"),
+    "manual63chapter": (UM63 + "#chapter.%s", "MCNP 6.3 manual § %s"),
+    "manual62": (UM62 + "#page=%s", "MCNP 6.2 manual p. %s"),
+    "issue": ("https://github.com/idaholab/MontePy/issues/%s", "#%s"),
+    "pull": ("https://github.com/idaholab/MontePy/pull/%s", "#%s"),
 }
 
 

doc/source/developing.rst

@@ -23,12 +23,11 @@ Setting up and Typical Development Workflow
 #. Clone the repository.
 
 #. Install the required packages. 
-   MontePy comes with two requirements files. 
-   One (``requirements/common.txt``) is for packages MontePy depends on.
-   The other (``requirements/dev.txt``) is for packages that are generally necessary for developing.
-   To install these simply run: 
+   MontePy comes with the requirements specfied in ``pyproject.toml``.
+   Optional packages are also specified.
+   To install all packages needed for development simply run: 
 
-   ``pip install -r requirements/dev.txt``
+   ``pip install .[develop]``
 
 #. Tie your work to an issue. All work on MontePy is tracked through issues. 
    If you are working on a new feature or bug that is not covered by an issue, please file an issue first.
@@ -38,8 +37,8 @@ Setting up and Typical Development Workflow
    The easiest way to make this branch is to "create pull request" from github.
    This will create a new branch (though with an unwieldy name) that you can checkout and work on.
 
-#. Run the test cases. MontePy relies heavily on its over 200 tests for the development process.
-   These are configured so if you run: ``python -m pytest`` from the root of the git repository 
+#. Run the test cases. MontePy relies heavily on its over 380 tests for the development process.
+   These are configured so if you run: ``pytest`` from the root of the git repository 
    all tests will be found and ran.
 
 #. Develop test cases. This is especially important if you are working on a bug fix.
@@ -48,8 +47,8 @@ Setting up and Typical Development Workflow
    To achieve this, it is recommended that you commit the test first, and push it to gitlab.
    This way there will be a record of the CI pipeline failing that can be quickly reviewed as part of the merge request.
 
-   Though MontePy uses ``pytest`` for running the tests,
-   it actually uses `unittest <https://docs.python.org/3/library/unittest.html>`_ for setting up all test fixtures. 
+   MontePy is currently working on migrating from ``unittest`` to ``pytest`` for test fixtures.
+   All new tests should use a ``pytest`` architecture.
    Generally unit tests of new features go in the test file with the closest class name. 
    Integration tests have all been dumped in ``tests/test_integration.py``. 
    For integration tests you can likely use the ``tests/inputs/test.imcnp`` input file.
@@ -70,10 +69,10 @@ Setting up and Typical Development Workflow
    Otherwise just the docstrings may suffice.
    Another option is to write an example in the "Tips and Tricks" guide.
 
-#. Update the version, and authors as necessary. The version is stored in ``montepy/__init__.py``. See the version numbering system described in ``README.md``.
-   The authors information is in ``AUTHORS`` and ``montepy/__init__.py``. 
+#. Update the authors as necessary. 
+   The authors information is in ``AUTHORS`` and ``pyproject.toml``. 
 
-#. Start a merge request review. Generally Micah or Travis are good reviewers.
+#. Start a merge request review. Generally Micah (@micahgale) or Travis (@tjlaboss) are good reviewers.
 
 
 Deploy Process
@@ -97,32 +96,38 @@ Automated Versioning
 As part of the CD process a new version number is created. 
 The `GitHub action <https://github.com/laputansoft/github-tag-action>`_ that does this goes through the following process:
 
-1. Finds the last release version as git tags.
-2. Analyzes all commit messages since then to determine if this is a Major, Minor, or Patch release.
-3. Creates a tag with the apropriately incremented new release version.
+#. Finds the last release version as git tags.
+#. Analyzes all commit messages since then to determine if this is a Major, Minor, or Patch release.
+#. Creates a tag with the apropriately incremented new release version.
 
 This means that git commit messages needs to convey the appropriate level of information.
-The library uses `angular's commit message conventions <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines>`_.
 This convention will not be enforced for all commits,
 but will be for all merge commits from Pull Requests.
 
 Additional References:
 
-1. `github action <https://github.com/laputansoft/github-tag-action>`_
-1. `angular's commit message conventions <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines>`_
-1. `Semantic versioning standard <https://semver.org/>`_
+#. `github action <https://github.com/laputansoft/github-tag-action>`_
+#. `Semantic versioning standard <https://semver.org/>`_
 
 Merge Checklist
 ^^^^^^^^^^^^^^^
 
 Here are some common issues to check before approving a merge request.
 
 #. If this is a bug fix did the new testing fail without the fix?
-#. Was the version number incremented?
 #. Were the authors and credits properly updated?
-#. Check also the authors in ``montepy/__init__.py``
+#. Check also the authors in ``pyproject.toml``
 #. Is this merge request tied to an issue?
 
+Deploy Checklist
+^^^^^^^^^^^^^^^^
+
+For a deployment you need to:
+
+#. Update changelog version number.
+#. Tag the next version number.
+
+
 Package Structure
 -----------------
 

montepy/cell.py

@@ -37,8 +37,14 @@ class Cell(Numbered_MCNP_Object):
     .. versionchanged:: 0.2.0
         Removed the ``comments`` argument due to overall simplification of init process.
 
+
     :param input: the input for the cell definition
     :type input: Input
+
+    .. seealso::
+
+            * :manual63sec:`5.2`
+            * :manual62:`55`
     """
 
     _ALLOWED_KEYWORDS = {