SalishSeaCmd Package Development

Continuous Integration

Pytest with Coverage Status Codecov Testing Coverage Report CodeQL analysis

Documentation

Documentation Status Sphinx linkcheck

Package

Releases Python Version Issue Tracker

Meta

Licensed under the Apache License, Version 2.0 Git on GitHub pre-commit
The uncompromising Python code formatter Hatch project

Python Versions

Python Version

The SalishSeaCmd package is developed using Python 3.12. The minimum supported Python version is 3.11. The Continuous Integration workflow on GitHub ensures that the package is tested for all versions of Python>=3.11. An old version of the package running under Python 3.5 is depoloyed on the Westgrid orcinus HPC platform. That version is tagged in the repository as orcinus-python-3.5.

Getting the Code

Git on GitHub

Clone the SalishSeaCmd code and documentation repository from GitHub with:

$ git clone git@github.com:SalishSeaCast/SalishSeaCmd.git

Development Environment

The SalishSeaCmd package depends on the NEMO-Cmd package, so you need to clone its repo, NEMO-Cmd, beside your clone of SalishSeaCmd.

Setting up an isolated development environment using Conda is recommended. Assuming that you have Anaconda Python Distribution or Miniconda3 installed, you can create and activate an environment called salishsea-cmd that will have all of the Python packages necessary for development, testing, and building the documentation with the commands:

$ conda env create -f SalishSeaCmd/envs/environment-dev.yaml
$ conda activate salishsea-cmd
(salishsea-cmd)$ pip install --editable NEMO-Cmd
(salishsea-cmd)$ pip install --editable SalishSeaCmd

The --editable option in the pip install commands above installs the NEMO-Cmd package and the SalishSeaCmd packages via symlinks so that salishsea in the salishsea-cmd environment will be automatically updated as the repos evolve.

To deactivate the environment use:

(salishsea-cmd)$ conda deactivate

Coding Style

pre-commit The uncompromising Python code formatter

The SalishSeaCmd package uses Git pre-commit hooks managed by pre-commit to maintain consistent code style and and other aspects of code, docs, and repo QA.

To install the pre-commit hooks in a newly cloned repo, activate the conda development environment, and run pre-commit install:

$ cd SalishSeaCmd
$ conda activate nemo-cmd
(nemo-cmd)$ pre-commit install

Note

You only need to install the hooks once immediately after you make a new clone of the SalishSeaCmd repository and build your Development Environment.

Building the Documentation

Documentation Status

The documentation for the SalishSeaCmd package is written in reStructuredText and converted to HTML using Sphinx.

If you have write access to the repository on GitHub, whenever you push changes to GitHub the documentation is automatically re-built and rendered at https://salishseacmd.readthedocs.io/en/latest/.

Additions, improvements, and corrections to these docs are always welcome.

The quickest way to fix typos, etc. on existing pages is to use the Edit on GitHub link in the upper right corner of the page to get to the online editor for the page on GitHub.

For more substantial work, and to add new pages, follow the instructions in the Development Environment section above. In the development environment you can build the docs locally instead of having to push commits to GitHub to trigger a build on readthedocs.org and wait for it to complete. Below are instructions that explain how to:

  • build the docs with your changes, and preview them in Firefox

  • check the docs for broken links

Building and Previewing the Documentation

Building the documentation is driven by docs/Makefile. With your salishsea-cmd development environment activated, use:

(salishsea-cmd)$ (cd docs && make clean html)

to do a clean build of the documentation. The output looks something like:

Removing everything under '_build'...
Running Sphinx v3.0.0
making output directory... done
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from http://salishsea-meopar-docs.readthedocs.io/en/latest/objects.inv...
loading intersphinx inventory from http://nemo-cmd.readthedocs.io/en/latest/objects.inv...
intersphinx inventory has moved: http://nemo-cmd.readthedocs.io/en/latest/objects.inv -> https://nemo-cmd.readthedocs.io/en/latest/objects.inv
intersphinx inventory has moved: http://salishsea-meopar-docs.readthedocs.io/en/latest/objects.inv -> https://salishsea-meopar-docs.readthedocs.io/en/latest/objects.inv
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 10 source files that are out of date
updating environment: [new config] 10 added, 0 changed, 0 removed
reading sources... [100%] subcommands
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] subcommands
generating indices...  genindexdone
highlighting module code... [100%] salishsea_cmd.api
writing additional pages...  searchdone
copying static files... ... done
copying extra files... done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded.

Build finished. The HTML pages are in _build/html.

The HTML rendering of the docs ends up in docs/_build/html/. You can open the index.html file in that directory tree in your browser to preview the results of the build before committing and pushing your changes to GitHub.

Whenever you push changes to the SalishSeaCmd on GitHub the documentation is automatically re-built and rendered at https://salishseacmd.readthedocs.io/en/latest/.

Running the Unit Tests

The test suite for the SalishSeaCmd package is in SalishSeaCmd/tests/. The pytest tool is used for test fixtures and as the test runner for the suite.

With your salishsea-cmd development environment activated, use:

(salishsea-cmd)$ cd SalishSeaCmd/
(salishsea-cmd)$ pytest

to run the test suite. The output looks something like:

============================ test session starts =============================
platform linux -- Python 3.8.2, pytest-5.4.1, py-1.8.1, pluggy-0.13.1
Using --randomly-seed=1586216909
rootdir: /media/doug/warehouse/MEOPAR/SalishSeaCmd
plugins: randomly-3.2.1, cov-2.8.1
collected 279 items

tests/test_run.py ............................................................
..............................................................................
..............................................................................
.............................                                           [ 87%]
tests/test_api.py ......                                                [ 89%]
tests/test_split_results.py ................                            [ 95%]
tests/test_prepare.py ............                                      [100%]

============================ 279 passed in 1.96s =============================

You can monitor what lines of code the test suite exercises using the coverage.py and pytest-cov tools with the command:

(salishsea-cmd)$ cd SalishSeaCmd/
(salishsea-cmd)$ cpytest --cov=./

The test coverage report will be displayed below the test suite run output.

Alternatively, you can use

(salishsea-cmd)$ pytest --cov=./ --cov-report html

to produce an HTML report that you can view in your browser by opening SalishSeaCmd/htmlcov/index.html.

Continuous Integration

Pytest with Coverage Status Codecov Testing Coverage Report

The SalishSeaCmd package unit test suite is run and a coverage report is generated whenever changes are pushed to GitHub. The results are visible on the repo actions page, from the green checkmarks beside commits on the repo commits page, or from the green checkmark to the left of the “Latest commit” message on the repo code overview page . The testing coverage report is uploaded to codecov.io

The GitHub Actions workflow configuration that defines the continuous integration tasks is in the .github/workflows/pytest-with-coverage.yaml file.

Version Control Repository

Git on GitHub

The SalishSeaCmd package code and documentation source files are available in the SalishSeaCmd Git repository at https://github.com/SalishSeaCast/SalishSeaCmd.

Issue Tracker

Issue Tracker

Development tasks, bug reports, and enhancement ideas are recorded and managed in the issue tracker at https://github.com/SalishSeaCast/SalishSeaCmd/issues.

License

Licensed under the Apache License, Version 2.0

The SalishSeaCast NEMO command processor and documentation are copyright 2013 – present by the SalishSeaCast Project Contributors and The University of British Columbia.

They are licensed under the Apache License, Version 2.0. https://www.apache.org/licenses/LICENSE-2.0 Please see the LICENSE file for details of the license.

Release Process

Releases Hatch project

Releases are done at Doug’s discretion when significant pieces of development work have been completed.

The release process steps are:

  1. Use hatch version release to bump the version from .devn to the next release version identifier

  2. Confirm that docs/breaking_changes.rst includes any relevant notes for the version being released

  3. Commit the version bump and breaking changes log update

  4. Create an annotated tag for the release with Git -> New Tag… in PyCharm or git tag -e -a vyy.n

  5. Push the version bump commit and tag to GitHub

  6. Use the GitHub web interface to create a release, editing the auto-generated release notes as necessary

  7. Use the GitHub Issues -> Milestones web interface to edit the release milestone:

    • Change the Due date to the release date

    • Delete the “when it’s ready” comment in the Description

  8. Use the GitHub Issues -> Milestones web interface to create a milestone for the next release:

    • Set the Title to the next release version, prepended with a v; e.g. v23.1

    • Set the Due date to the end of the year of the next release

    • Set the Description to something like v23.1 release - when it's ready :-)

    • Create the next release milestone

  9. Review the open issues, especially any that are associated with the milestone for the just released version, and update their milestone.

  10. Close the milestone for the just released version.

  11. Use hatch version minor,dev to bump the version for the next development cycle, or use hatch version major,minor,dev for a year rollover version bump

  12. Commit the version bump

  13. Push the version bump commit to GitHub