Site Web App

Continuous Integration

Pytest with Coverage Status Codecov Testing Coverage Report CodeQL analysis


Documentation Status Sphinx linkcheck


Releases Python Version from PEP 621 TOML Issue Tracker


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

The site is a dynamic web application written in Python 3 using the Pyramid web framework. These docs provide a brief explanation of the structure of the app, and details about its development.

If you are new to Python web frameworks you should probably start by reading the Pyramid Hello World docs, and then maybe proceed to the Quick Tutorial.

If you have experience with any of the many other Python web frameworks such as Django, flask, bottle, etc. you could start with the Quick Tutorial, or dive into the narrative documentation.

App Structure

The salishsea_site directory tree contains the app package:

  • The app configuration is defined in salishsea_site/ That file also contains functions that map URL paths to route names. It also contains static view functions that serve the site static assets (see below) and model run results figures and other static files produced by the Salish Sea NEMO and SOG 1-D models.

  • The salishsea_site/views/ directory contains Python modules that define the view functions that the routes connect to. The view functions handle the HTTP requests coming into the app, and calculate the dynamic elements of the responses which are returned by the functions as dict objects. The view modules are organized to correspond to the site’s top-of-page navigation bar.

  • The salishsea_site/templates/ directory tree contains the page templates that the view functions pass to the renderer to produce the HTML stream that is sent to the user’s browser in the HTTP response. The dict objects returned by the view functions contain the template variable names and the values to substitute for them. The templates are written in HTML5. They use the Bootstrap 3 HTML/CSS/JS framework for layout and client-side dynamic elements. The Mako template library is used to provide variable substitution, inheritance, and flow control in the templates. The templates are organized in sub-directories that correspond to the view modules.

  • The salishsea_site/static/ directory tree contains the app’s static assets, CSS files, images, and PDF documents. They are served by a static view defined in salishsea_site/

The runtime configurations for running the app in a development environment, and for its production deployment are contained in the development.ini and production.ini files in the top level of the repository.

Please see Web App Package Development for details of how to set up an app development environment, and Running the App in Dev Mode for instructions on how to run the app in development mode on your local machine.

The tests/ directory tree contains the unit test suite for the package. It is intended to be run using the pytest tool. Please see Running the Unit Tests for details.

The docs/ directory tree contains the reStructuredText source files for these docs, and the Sphinx configuration and Makefile to render them to HTML. Please see Building the Documentation for details.

Web App Package Development

Python Versions

Python Version

The salishsea-site package is developed, tested, and deployed using Python 3.12.

Getting the Code

Git on GitHub

Clone the salishsea-site code and documentation repository from GitHub with:

$ git clone


$ git clone

if you don’t have ssh key authentication set up on GitHub (or copy the link from the Clone or download button on the repository page).

Development Environment

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

$ cd salishsea-site
$ conda env create -f env/environment-dev.yaml

The salishsea-site package is installed in editable install mode as part of the conda environment creation process. That means that the package is installed from the cloned repo via symlinks so that it will be automatically updated as the repo evolves.

To deactivate the environment use:

(salishsea-site)$ conda deactivate

Coding Style

pre-commit The uncompromising Python code formatter

The salishsea-site 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 salishsea-site
$ conda activate salishsea-site
(salishsea-site)$ pre-commit install


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

Running the App in Dev Mode

You can run the app in a development server on you local machine with the command:

(salishsea-site)$ cd salishsea-site
(salishsea-site)$ pserve --reload development.ini

With the dev server running you can view the site by navigating to http://localhost:6543/ in your browser.

The --reload option in the pserve command causes the dev server to monitor the app files in the salishsea-site/ directory tree and restart whenever it detects that a file has been changed. That allows you to easily edit app code and templates and instantly see changes in your browser after a page refresh.

Logger messages from the app appear in the terminal session where you ran the pserve command.

To stop the dev server use Ctrl-C in the terminal session where you ran the pserve command.


Several pages in the app require access to parts of the /results/ directory tree on skookum. If you are working on a waterhole machine that has /results/ mounted, you are good to go. If you need to get /results/ mounted on a waterhole machine, please open an EOAS IT ticket with the request. If you are working on a remote machine or a laptop you can use sshfs to mount /results/ from skookum at a local /results/ mount point.

Building the Documentation

Documentation Status

The documentation for the salishsea-site 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

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 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 the docs/Makefile. With your salishsea-site development environment activated, use:

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

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

Removing everything under '_build'...
Running Sphinx v7.2.6
making output directory... done
loading intersphinx inventory from
loading intersphinx inventory from
building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 1 source files that are out of date
updating environment: [new config] 1 added, 0 changed, 0 removed
reading sources... [100%] index
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
copying assets... copying static files... done
copying extra files... done
writing output... [100%] index
generating indices... genindex done
writing additional pages... search done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded.

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 Bitbucket.

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

Running the Unit Tests

The test suite for the salishsea-site package is in salishsea-site/tests/. The pytest tools is used for test fixtures and as the test runner for the suite.

With your salishsea-site development environment activated, use:

(salishsea-site)$ cd salishsea-site/
(salishsea-site)$ py.test

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

============================ test session starts ============================
platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0
rootdir: /media/doug/warehouse/MEOPAR/salishsea-site
configfile: pyproject.toml
plugins: cov-5.0.0
collected 76 items

tests/ .......                                     [  9%]
tests/views/ ..                                       [ 11%]
tests/views/ ...                                        [ 15%]
tests/views/ .....................................
...........................                                            [100%]
============================ 76 passed in 0.72s =============================

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

(salishsea-site)$ cd salishsea-site/
(salishsea-site)$ pytest --cov=./

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

Alternatively, you can use

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

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

Continuous Integration

Pytest with Coverage Status Codecov Testing Coverage Report

The salishsea-site 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

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

Version Control Repository

Git on GitHub

The salishsea-site package code and documentation source files are available in the salishsea-site Git repository at

Issue Tracker

Issue Tracker

Development tasks, bug reports, and enhancement ideas are recorded and managed in the issue tracker at


Licensed under the Apache License, Version 2.0

The site content, code, and documentation are Copyright 2014 – present by the Mesoscale Ocean and Atmospheric Dynamics (MOAD) group in the Department of Earth, Ocean, and Atmospheric Sciences at The University of British Columbia. Please see for details.

They are licensed under the Apache License, Version 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; e.g. 24.1.dev0 to 24.1

  2. Commit the version bump

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

  4. Push the version bump commit and tag to GitHub

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

  6. 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

  7. 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. v24.2

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

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

    • Create the next release milestone

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

  9. Close the milestone for the just released version.

  10. 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

  11. Commit the version bump

  12. Push the version bump commit to GitHub