8.2.0
These release notes are automatically extracted from the full changelog.
Features
-
nextstrain build
andnextstrain shell
now better support pathogen repositories which place workflows in subdirectories. The top-level of the repo must contain anextstrain-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/
andphylogenetic/
contain workflows that useshared/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 tonextstrain 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
andnextstrain 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 ofnextstrain shell
since 5.0.0. (#354)