8.5.4

These release notes are automatically extracted from the full changelog.

Bug fixes

• It is no longer a fatal error if the logs for a completed AWS Batch job cannot be fetched for some reason. nextstrain build will warn about the error but continue on with printing the job status (e.g. success or reason for failure) and, if applicable, downloading job results. (#406)

8.5.3

These release notes are automatically extracted from the full changelog.

Bug fixes

• Authentication established via nextstrain login and used by the nextstrain remote family of commands no longer verifies the "issued at" (iat) time of the received tokens in order to avoid the following error:

  ImmatureSignatureError: The token is not yet valid (iat).
  

  This error was seen by users who's system time was slightly lagged, and it prevented them from logging in or renewing their authentication. (#394)

8.5.2

These release notes are automatically extracted from the full changelog.

Bug fixes

• The suggested commands to run (i.e. potential solutions) in expected errors from nextstrain remote now explicitly include the remote origin to avoid being incorrect or misleading for origins other than nextstrain.org. For example, if the error message suggested running nextstrain login, it now suggests nextstrain login https://nextstrain.org. (#391)

8.5.1

These release notes are automatically extracted from the full changelog.

Bug fixes

• nextstrain remote download now produces the expected local file names when there are periods (dots) in the remote dataset name (e.g. nextstrain remote download /a/b.c/d now produces a_b.c_d.json instead of a_b.json) and when there are periods in the given local file name (e.g. nextstrain remote download /x/y/z x.y.z now produces x.y.z.json instead of x.y.json). (#381)

8.5.0

These release notes are automatically extracted from the full changelog.

Improvements

• Snakemake's per-input/output file metadata (stored in .snakemake/metadata/) is now downloaded from AWS Batch builds by default. Like file modification times (mtimes), which are already preserved from the remote build, this additional metadata is used by Snakemake to track when inputs have changed and when it should regenerate outputs. The metadata is also used in Snakemake report generation and can be useful for gathering ad-hoc workflow statistics.

  The runtime image used must be at least nextstrain/base:build-20240617T235011Z for these Snakemake metadata files to be available for download from the AWS Batch job. (#374)

8.4.0

These release notes are automatically extracted from the full changelog.

This release adds explicit (i.e. tested) support for Python version 3.12. (#369)

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.

Features

• nextstrain build now supports two new options when using the AWS Batch runtime: --exclude-from-upload and --exclude-from-download. The former is useful for avoiding the upload of large, ancillary files not needed by the build. The latter exists to parallel the former and make it easier to exclude files from both upload and download. (#370)

Improvements

• The Conda runtime now uses Micromamba 1.5.8 (upgraded from 1.1.0) to manage the runtime environment. The newer version supports Zstandard-compressed index files which speeds up nextstrain setup and nextstrain update for the Conda runtime. (#367)

Bug fixes

• The --download option of nextstrain build now supports passing only negated patterns (e.g. !… and !(…)). All files which don't match the negated patterns will be downloaded. Previously, no files were downloaded unless at least one positive pattern was given. (#370)

8.3.0

These release notes are automatically extracted from the full changelog.

Improvements

• Commands which utilize a runtime—nextstrain build, nextstrain shell, and nextstrain view—now support specifying envdirs to forward into the runtime environment by setting NEXTSTRAIN_RUNTIME_ENVDIRS to a :-separated (; on Windows) list of paths. This is in addition to the existing support for specifying one or more --envdir options. (#365)

8.2.0

These release notes are automatically extracted from the full changelog.

Features

• nextstrain build and nextstrain shell now better support pathogen repositories which place workflows in subdirectories. The top-level of the repo must contain a nextstrain-pathogen.yaml file for this support to activate. The file may be empty for now, though we anticipate using it for pathogen-level metadata in the future to aid indexing, listing, and attribution of pathogen repos.

  As an example of the new support, consider the following repo layout

  mpox/
  ├── nextstrain-pathogen.yaml
  ├── ingest/
  │   ├── Snakefile
  │   └── …
  ├── phylogenetic/
  │   ├── Snakefile
  │   └── …
  ├── shared/
  │   ├── reference.fasta
  │   └── …
  └── …
  

  where ingest/ and phylogenetic/ contain workflows that use shared/reference.fasta via a relative path (i.e. ../shared/reference.fasta).

  It's now possible to invoke those workflows with any of the following:

  nextstrain build mpox/ingest/
  nextstrain build mpox/phylogenetic/
  
  cd mpox
  nextstrain build ingest/
  nextstrain build phylogenetic/
  
  cd phylogenetic
  nextstrain build .
  nextstrain build ../ingest/
  

  regardless of runtime.

  Previously, such workflows required careful invocation, e.g.

  nextstrain build mpox/ -d phylogenetic/ -s phylogenetic/Snakefile
  

  when using runtimes with filesystem isolation (i.e. the containerized ones; Docker, Singularity, and AWS Batch) but not when using runtimes without it.

  When active, this feature makes the top-level of the pathogen repo (e.g. mpox/) available in the container at /nextstrain/build while the initial working directory is set to the workflow subdirectory in the container (e.g. /nextstrain/build/phylogenetic). That is, the filesystem isolation boundary is drawn at the top-level of the pathogen repo instead of at the workflow directory (i.e. what's given to nextstrain build). (#355)

Improvements

• We now produce standalone installation archives for macOS running on aarch64 hardware (aka arm64, Apple Silicon, M1/M2). The standalone installer will use these archives starting with this release. (#357, #358)

• The Conda and Docker runtime checks performed by nextstrain setup and nextstrain check-setup now test if Rosetta 2 is enabled for macOS on aarch64 (aka arm64, Apple Silicon, M1/M2) hardware. Rosetta is required for the Conda runtime and optional, but recommended, for the Docker runtime. Previously only the standalone installer checked for Rosetta, but starting with this release it will not. (#361, #358)

• nextstrain build now errors if a development overlay option such as --augur or --auspice is given when using a runtime without support for those (anything but Docker or Singularity). Previously, it would silently ignore those options when unsupported by the runtime. The new behaviour matches the behaviour of nextstrain shell since 5.0.0. (#354)

8.0.1

These release notes are automatically extracted from the full changelog.

Improvements

• Several kinds of errors from nextstrain login and nextstrain whoami related to their interactions with a remote server are now clearer. (#347)

8.0.0

These release notes are automatically extracted from the full changelog.

This release drops support for Python versions 3.6 and 3.7 and adds support for 3.11. (#325, #327)

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

• The nextstrain remote family of commands now support alternative nextstrain.org-like remotes such as internal Nextstrain Groups Server instances and development instances of nextstrain.org. Authentication with these remotes is supported via nextstrain login and related commands. Remotes maintain their authentication alongside each other, e.g. you can be logged into nextstrain.org as well as an alternative nextstrain.org-like instance.

  As an example, a Nextstrain Groups Server instance accessible at nextstrain.example.com could now be logged into and interacted with like so:

  nextstrain login nextstrain.example.com
  nextstrain whoami nextstrain.example.com
  nextstrain remote ls nextstrain.example.com/groups/bedford-lab/
  

  The default remote is still nextstrain.org. (#333)

• nextstrain login now performs authentication via a web browser by default (using OpenID Connect 1.0 and OAuth 2.0). The previously method of direct password entry is still used when a username is provided (e.g. with --username or -u). See nextstrain login --help for more information. (#333)

• With the new support for being logged into multiple remotes, nextstrain logout now also supports an --all flag to remove all locally-saved credentials without having to logout of each remote separately. (#333)

• nextstrain remote upload now skips gzip compression when uploading zstandard-compressed (.zst) files, matching its behaviour for other types
  of compressed files. (#330)

• Commands that may automatically open a web browser, e.g. nextstrain view or nextstrain login, now respect the semi-conventional NOBROWSER environment variable to disable opening a browser. Set NOBROWSER to a non-empty value to disable automatic opening. When disabled, the URL to manually open will be shown. (#332)

• The error message emitted by the nextstrain remote family of commands when they're unable to access an S3 bucket now lists a few possible reasons for the failure. (#341)

• nextstrain remote download now supports downloading core datasets which are only visible on the web by direct access via their URL. For example, the following now work (where in previous versions they did not):

  nextstrain remote download https://nextstrain.org/nextclade/sars-cov-2/21L
  nextstrain remote download https://nextstrain.org/enterovirus/d68/vp1/2020-01-23
  

  This support also covers past snapshots of datasets, which is a recently-added feature to nextstrain.org. For example:

  nextstrain remote download https://nextstrain.org/flu/seasonal/h3n2/ha/6y@2023-07-01
  nextstrain remote download https://nextstrain.org/ncov/gisaid/21L/global/6m@2024-01-09
  

  (#345)

Bug fixes

• Commands making use of user authentication (e.g. nextstrain login, nextstrain whoami, some invocations of nextstrain remote, etc.) no longer fail if the logged in user is a member of no groups. (#323)

• On Linux and macOS, the standalone installer's final instructions now correctly suggest modifying ~/.profile instead of, incorrectly, ~/.shrc when the default shell is sh. (#321)

• The Singularity runtime once again supports Apptainer's singularity executable. The minimum version checking added in 7.0.0 broke usage of the Singularity runtime with Apptainer (compared with SingularityCE). Our intent is to support both lineages of Singularity. Thanks to @osageorange for raising this issue and testing the fix! (#343)