10.3.0

These release notes are automatically extracted from the full changelog.

This release adds explicit (i.e. tested) support for Python version 3.13. (#473)

Note that this Python version support only matters if you're installing Nextstrain CLI from PyPI or Bioconda (c.f.). It does not apply if you're installing Nextstrain CLI using the standalone installation method we recommend in the Nextstrain installation documentation. In that case, a supported Python version is always bundled with nextstrain.

Improvements

• nextstrain setup <pathogen> and nextstrain version --pathogens now list the available workflows (e.g. ingest, phylogenetic) for a pathogen if the workflows are registered as compatible with nextstrain run in the pathogen's nextstrain-pathogen.yaml file. (#461, #472)

• Snakemake's storage support downloaded files (stored in .snakemake/storage/) are now downloaded from AWS Batch builds by default.

  The runtime image used must be at least nextstrain/base:build-20250721T201347Z for these Snakemake storage files to be available for download from the AWS Batch job. (#460)

• nextstrain run now supports an alternative invocation where a path to a local directory that is a pathogen repository can be given instead of a pathogen name (and optionally version). This allows nextstrain run to be used with pathogen repos managed outside of Nextstrain CLI (i.e. not by nextstrain setup and nextstrain update), which can be useful for the analysis directory support and local testing. The workflow to run is still given separately by name (not path). (#476)

• When nextstrain setup <pathogen> and nextstrain update <pathogen> encounter an authentication error downloading from pathogen source URLs, the error message now includes a hint, if applicable, noting the presence of netrc-provided credentials and possible resolutions. This aids in resolving errors arising from stale GitHub credentials present in some users' netrc files (as managed by older versions of the GitHub CLI, gh). (#479)

• When Nextstrain CLI detects that a new version of itself is available, it will now output the instructions on how to upgrade to that new version after (instead of before) the normal output from the running command. This makes it easier to find and follow the instructions when output is long. The notices of the new version will be output both before and after normal output. (#475)

• For most installation methods (i.e. standalone, Pip, pipx, and Conda), the process of updating Nextstrain CLI itself is now automated by a single nextstrain update cli command. This is suggested in new version notices emitted by automatic new version checks (along with the previously-suggested update commands that vary by installation method). Integrating with nextstrain update puts updates to the CLI alongside updates to the runtimes and pathogens. (#475)

Bug fixes

• nextstrain setup <pathogen>@<version> and nextstrain update <pathogen>@<version> no longer result in a 404 error if <version> includes a slash and it is a valid version specifier. (#459)

• Reverting changes made in 10.2.1, nextstrain setup <pathogen> and nextstrain update <pathogen> will once again attempt to use a local netrc file for authentication when downloading pathogen source URLs. This also reinstates support in those cases for configuring outgoing network proxies and CA certificate trust stores via environment variables. Support for private repositories is not unintentional and is something we intend to provide. (#478)

• nextstrain run now overrides (i.e. suppresses) any "workdir:" directives in a workflow by explicitly setting the working directory when it invokes Snakemake. This avoids writing files into the pathogen/workflow source directories when non-compatible (or broken) workflows are used with nextstrain run despite the warnings issued. Such workflows are more likely to error and fail now early on rather than "succeed" but produce output files in the wrong location. (#476)

• When a standalone installation of Nextstrain CLI suggests a command to run to update itself, that command now takes into account non-default installation paths so that the new version is installed to the same place as the current version. (#474)