Housekeeping

Prerequisites Checklist

Self-review checklist:

• My code follows the style guidelines and software coding standards for this project.
• I have performed a self-review of my code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added appropriate tests that prove my fix/feature is effective.
• If the source branch will not be used after this MR, I have set it to be deleted upon merging.

Documentation checklist:

• I have checked the README and updated it if necessary.
• I have checked the tutorial and made any documenation or results updates if necessary.
• I have updated the CHANGELOG.

Does this MR relate to a specific issue? If so, link the issue.

Addresses multiple issues: #94 (closed) #82 (closed) #83 (closed) (and I think technically #71 (closed) as well since this standardizes the dependencies setup a bit more)

There are a few issues that I was hoping to maybe address with this MR as well, but I am unsure exactly how to do that. If it is easy to address any of these things, let me know how and I can tack it on: #86 #76

Description of Changes

A series of house keeping, maintenance changes and additions here:

• I added MR templates for standard MRs and Release MRs (I am using the standard template here). I think when this gets merged, the templates should appear, though it is possible that they won't appear until they get merged into master. Note: I did not make an Issues template since we have so many different types of issues already. I think any issues made by developers are/have been descriptive enough.
• I removed the .pyarc.rc.testing file since it was not used anywhere in CI and seems to have confused some new users.
• Minor change to the PyARC.py file to put the version and release date up at the top so it is easier to find and update. It can also be imported into other modules if necessary this way.
• Multiple scripts have been removed:
  • setup_dependencies.sh: The source builds happening were no longer necessary. Instead, the bin/ and wasppy/ folders from workbench are linked in the repo, which is what is instructed to do in the README anyway.
  • setup_joblib.sh: Joblib is available in the WB env now and no longer required to build/install separately.
  • package_pyarc.sh: Since PyARC cannot be used without WB, it does not makes sense to package it separately, nor do I think this script worked.
• The setup scripts that manage DASSH, OpenMC, and PyGriffin have all been slightly reworked (and renamed for consistency) to be automatically called in one go through install_dependencies.sh. Now that PyGriffin is available as open-source, I made it the same setup in DASSH where the default behavior is to clone the repo for the specified version, but a user can alternatively provide a path to a preexisting repo. I changed the default download location for these two to be the PyARC source dir instead of the ARC executables dir since (a) that caused some permission issues in CI and (b) I would think some users could encounter similar issues. Each of the three codes can still be installed individually by running the _X_install.sh scripts independently, but the install_dependencies.sh script takes care of doing all of them easily.
• The python version check in setup_conda.sh has been fixed to check explicitly for minor and major version since it was flagging v3.11 as "too low" (user reported bug)
• docgen.sh has been fixed to account for differences in how sed -i is executed on different operating systems. Also for the sake of CI checking, I added the requirement that pandoc be v3.1 (otherwise there are slight differences in file generation).
• README (and corresponding HTML) have been updated with the changes to the setup scripts.
• The CI configuration has been updated for a few things:
  • uses the new setup scripts
  • Adds two new stages that are to be executed only when a "release" MR is made (ie, MR into master). See draft MR !248 (closed) into master just for the purpose of demo.
    • test_tutorial- this runs the tutorial tests. NOTE: these tests do not currently pass, but I deemed the failures too large for addressing in this MR. So this will still need addressing before the next release.
    • check_documentation: this stage has two purposes: (1) make sure the generation script works, (2) ensure that the HTML documentation has been regenerated for the release.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected or break backwards compatibility)

This is "breaking" in that the setup scripts are new, but the source code is not changed.

Additional Information