Skip to content

8.2.0
Compare
Choose a tag to compare
@github-actions github-actions released this 07 Feb 00:43
8.2.0
1f86a5f

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)

Assets 8
Loading