diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 7c339d9e..ab4d2d66 100644 --- a/.github/workflows/main.yml +++ b/.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 diff --git a/.gitignore b/.gitignore index 990257f6..31c5a32f 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,6 @@ __pycache__/ build/* +doc/build dist/* *egg-info/* *.mcnp diff --git a/README.md b/README.md index 860b3edb..aab0b7df 100644 --- a/README.md +++ b/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! diff --git a/doc/source/_test_for_missing_docs.py b/doc/source/_test_for_missing_docs.py index c6ad78f1..41e8a870 100644 --- a/doc/source/_test_for_missing_docs.py +++ b/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("..", "..") diff --git a/doc/source/changelog.rst b/doc/source/changelog.rst index 2f49e2af..9a6b5de8 100644 --- a/doc/source/changelog.rst +++ b/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 -------------------- diff --git a/doc/source/conf.py b/doc/source/conf.py index 12cb3342..8b083bc9 100644 --- a/doc/source/conf.py +++ b/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"), } diff --git a/doc/source/developing.rst b/doc/source/developing.rst index 6f740325..bc6569db 100644 --- a/doc/source/developing.rst +++ b/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 `_ 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,20 +96,18 @@ Automated Versioning As part of the CD process a new version number is created. The `GitHub 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 `_. This convention will not be enforced for all commits, but will be for all merge commits from Pull Requests. Additional References: -1. `github action `_ -1. `angular's commit message conventions `_ -1. `Semantic versioning standard `_ +#. `github action `_ +#. `Semantic versioning standard `_ Merge Checklist ^^^^^^^^^^^^^^^ @@ -118,11 +115,19 @@ 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 ----------------- diff --git a/montepy/cell.py b/montepy/cell.py index 3e9558e4..b2f92479 100644 --- a/montepy/cell.py +++ b/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 = {