Development guide#

This page describes how to develop Templatekit, the Python package. For information on developing templates in a template repository, see the Template development guide.

Scope of contributions#

Templatekit is an open source package, meaning that you can contribute to Templatekit itself, or fork Templatekit for your own purposes.

Since Templatekit is intended for internal use by Rubin Observatory, community contributions can only be accepted if they align with Rubin Observatory’s aims. For that reason, it’s a good idea to propose changes with a new GitHub issue before investing time in making a pull request.

Templatekit is developed by the LSST SQuaRE team.

Setting up a local development environment#

To develop Safir, create a virtual environment with your method of choice (like virtualenvwrapper) and then clone or fork, and install:

git clone --recursive-submodules https://github.com/lsst-sqre/templatekit
cd templatekit
make init

This init step does four things:

  1. Clones Templatekit with test data (lsst/templates).

  2. Installs Templatekit in an editable mode with its “dev” extra that includes test and documentation dependencies.

  3. Installs pre-commit and tox.

  4. Installs the pre-commit hooks.

Pre-commit hooks#

The pre-commit hooks, which are automatically installed by running the make init command on set up, ensure that files are valid and properly formatted. Some pre-commit hooks automatically reformat code:

isort

Automatically sorts imports in Python modules.

black

Automatically formats Python code.

blacken-docs

Automatically formats Python code in reStructuredText documentation and docstrings.

When these hooks fail, your Git commit will be aborted. To proceed, stage the new modifications and proceed with your Git commit.

Running tests#

To test the library, run tox, which tests the library the same way that the CI workflow does:

tox

To see a listing of test environments, run:

tox -av

To run a specific test or list of tests, you can add test file names (and any other pytest options) after -- when executing the py tox environment. For example:

tox -e py -- tests/database_test.py

Occasionally you may need to update the tests/data/templates submodule:

git submodule update --recursive

Building documentation#

Documentation is built with Sphinx:

tox -e docs

The build documentation is located in the docs/_build/html directory.

Updating the change log#

Each pull request should update the change log (CHANGELOG.rst). Add a description of new features and fixes as list items under a section at the top of the change log called “Unreleased:”

Unreleased
----------

- Description of the feature or fix.

If the next version is known (because Templatekit’s master branch is being prepared for a new major or minor version), the section may contain that version information:

X.Y.0 (unreleased)
------------------

- Description of the feature or fix.

If the exact version and release date is known (because a release is being prepared), the section header is formatted as:

X.Y.0 (YYYY-MM-DD)
------------------

- Description of the feature or fix.

Style guide#

Code#

  • The code style follows PEP 8, though in practice lean on Black and isort to format the code for you.

  • Use PEP 484 type annotations. The tox -e typing test environment, which runs mypy, ensures that the project’s types are consistent.

  • Write tests for Pytest.

Documentation#