The Nextstrain command-line interface (CLI)—a program called nextstrain—which aims to provide a consistent way to run and visualize pathogen builds and access Nextstrain components like Augur and Auspice across computing environments such as Docker, Conda, and AWS Batch.

Nextstrain CLI Development

Development of nextstrain-cli happens at https://github.com/nextstrain/cli.

We currently target compatibility with Python 3.6 and higher.

Versions for this project follow the Semantic Versioning rules.

Setup

Setup an isolated development environment in .venv/ with:

./devel/setup-venv

Activate the venv to run any of the commands below:

source .venv/bin/activate

(Or alternatively, run the commands below via ./devel/venv-run ….)

Now test that you can run:

nextstrain --help

The development environment includes our dev tools (described below):

pytest           # runs doctests as well as mypy and flake8
mypy -p nextstrain.cli
flake8

Running with local changes

The project is installed into editable mode when using the venv setup above, so any changes you make during development will be used automatically.

If you need to run with local changes in setups without editable mode, you can run ./bin/nextstrain to test your local changes without installing them. (Note that ./bin/nextstrain is not the script that gets installed by pip as nextstrain; that script is generated by the entry_points configuration in setup.py.)

Releasing

New releases are made frequently and tagged in git using a signed tag. There is a ./devel/release script which will prepare a new release from your local repository. It ends with instructions for you on how to push the release commit/tag.

When a release tag is pushed, the CI workflow builds source distributions and built distributions (wheels), tests them, and if tests pass, uploads them to the nextstrain-cli project on PyPi.

Tests

Tests are run with pytest. To run everything, use:

pytest

This includes the type annotation and static analysis checks described below.

Type annotations and static analysis

Our goal is to gradually add type annotations to our code so that we can catch errors earlier and be explicit about the interfaces expected and provided. Annotation pairs well with the functional approach taken by the package.

During development you can run static type checks using mypy:

$ mypy nextstrain
# No output is good!

and pyright:

$ npx pyright
...
Found 40 source files
0 errors, 0 warnings, 0 infos
Completed in 2sec

There are also many editor integrations for mypy, and Pyright is integrated into VS Code’s Python support.

The typing_extensions module should be used for features added to the standard typings module after 3.6.

We also use Flake8 for some static analysis checks focusing on runtime safety and correctness. You can run them like this:

$ flake8
# No output is good!