# Migrating from Snakemake to Nextflow: A Strategic Guide By the end of this guide you will be able to inventory an existing Snakemake project, translate its rules into Nextflow DSL2 processes, map your Conda environments to containers, run the migrated pipeline with caching and resumption, and validate that the new pipeline produces the same outputs as the old one. You will also know the mistakes that cost migration teams the most time and how to avoid them. Before you start, have the following on hand: - A working Snakemake project with a `Snakefile`, at least one Conda environment file or container directive, and a small test dataset that runs end to end in minutes. - Java 11 or newer installed (recent Nextflow releases have their own requirements, so check the documentation for the exact version you plan to run). - Nextflow itself, installed with the standard bootstrap script: ```bash curl -s https://get.nextflow.io | bash ./nextflow -v # Expected output: nextflow version 24.x.x or similar ``` - Git, if you plan to track the migration as a branch rather than a rewrite. - Access to either a local machine, an HPC cluster with a scheduler such as SLURM, or a cloud account, depending on where the pipeline will finally run. A note on scope: this guide covers the mechanics and strategy of moving a pipeline. It does not argue that Nextflow is always the right answer. Choosing a workflow manager is a design decision, and the research literature recommends prototyping on your own workload before committing, as the RiboViz project did when it compared workflow managers against a hand-written Python implementation [1]. ## Why Teams Migrate From Snakemake to Nextflow The honest answer to the "nextflow vs snakemake" question is that both are mature, widely adopted command-line workflow managers, and both produce [reproducible bioinformatics](/blog/guides/reproducible-bioinformatics-files-environments-parameters-and-provenance). A recent survey of community practice describes the two as the most popular command-line solutions, complementing graphical platforms such as Galaxy, and notes that both contribute to FAIR (Findable, Accessible, Interoperable, Reusable) research [2]. So the decision to migrate is rarely about correctness. It is usually about one or more of the following: - **Ecosystem gravity.** The nf-core framework, built on Nextflow, provides a large library of community-maintained modules and subworkflows under DSL2. Teams that want to reuse tested components instead of writing them find this library a strong pull. Snakemake has its own wrapper and module ecosystem, but if your collaborators, target journal, or new employer runs nf-core pipelines, working in Nextflow reduces friction. - **Execution model.** Nextflow treats data as channels flowing between processes, which favors explicit dataflow design. Snakemake infers the task graph from file-target matching against wildcard patterns. Both work. Some teams find the explicit channel model easier to reason about when composing subworkflows, and the software-engineering literature argues that well-defined task interfaces and explicit input and output specifications improve reuse and maintainability regardless of the tool [3]. - **Deployment story.** Nextflow bundles container-native execution, HPC schedulers, and cloud backends under one configuration surface. Published Nextflow pipelines routinely advertise that they run locally or on HPC systems using Conda, Singularity, or Docker with the same code, as scalepopgen does for population genomic workflows [4]. Snakemake also supports all of these, but the profile and configuration conventions differ, and Nextflow's single `nextflow.config` plus profile pattern has become a de facto standard. - **Resume semantics.** Nextflow hashes every task's inputs, script, and container into a work directory and skips identical tasks on `nextflow run -resume`. Snakemake offers incremental rebuilds and re-execution of parts of a workflow as well, a capability the workflow-management literature considers essential [1], but the hashing model makes the cache boundary more predictable in the common case of partial reruns after a code change. If none of these apply to your situation, the strategic advice is simple: do not migrate. Migration has real cost, and a working Snakemake pipeline that your team understands is an asset. The rest of this guide assumes you have made the decision for a concrete reason. ### A concept-by-concept comparison ![Three-column comparison of Snakemake rules, Nextflow processes and the practical change for sample identity, threads, environments and resume.](/article-images/illustrations/migrate-snakemake-to-nextflow-concept-mapping.webp) | Snakemake concept | Nextflow equivalent | What changes in practice | |, - |, - |, - | | `rule` | `process` | Processes do not know their sample names. Channels carry them. | | Wildcards such as `{sample}` | Channel keys, usually a `meta` map | You pass sample identity explicitly instead of letting pattern matching infer it. | | `input:` and `output:` file lists | `input:` and `output:` blocks fed by channels | The DAG is expressed as dataflow, not inferred from target filenames. | | `threads:` | `cpus` (per process) or `cpus` in a label config | The directive name changes, and the scheduler-aware defaults live in `nextflow.config`. | | `conda:` directive with a YAML file | `conda` scope in config, or a container directive | Containers become the primary unit of reproducibility. | | `config.yaml` with `params` | `params` block in `nextflow.config` | Same idea, different file and syntax. | | `snakemake, use-conda` | `-profile` with a `conda` scope, or `-profile docker/singularity` | Execution backend becomes a profile choice, not a command-line flag. | | `.snakemake` hidden state directory | `work/` directory | The cache is visible, inspectable, and per-task. | | `snakemake -n` (dry run) | `-stub-run` with `stub:` blocks | Stub blocks let you test the DAG without executing real compute. | | `-rerun-incomplete`, rerun triggers | `-resume` | Nextflow hashes task definitions and reuses matching work directory entries. | | `-until`, `-omit-from` | Workflow composition, `-entry` for named entry points | You select subgraphs in code rather than with target rules. | | `snakemake, dag` | `nextflow dag` | Both render the task graph for inspection. | ## Before You Migrate: Decide Whether You Should The research on choosing a workflow manager is blunt about the right method: prototype. The RiboViz team reimplemented an existing Python-driven workflow under candidate workflow managers specifically to evaluate them against their real workload rather than vendor claims or feature checklists [1]. You can borrow their approach cheaply, even when you already lean toward Nextflow: 1. Pick one representative subgraph of your pipeline, for example read trimming plus alignment. 2. Implement it in Nextflow against the same test data. 3. Measure the things that matter to you: time to first result, wall time on your scheduler, effort to debug a failing task, and effort to add one new step. 4. Compare against your existing Snakemake implementation on the same measures. This prototype is throwaway code with a real purpose. It also becomes the seed of your migration, because you will have already solved your first channel-conversion problems on a small, low-risk slice. One more decision to make before writing code: what does "migrated" mean for your project? Two common definitions are in play, and they lead to different plans: - **Behavioral parity.** The Nextflow pipeline produces byte-identical or analytically identical outputs to the Snakemake pipeline on the same inputs and versions. This is the goal when the pipeline supports published results or ongoing production. - **Modernization.** You are allowed to restructure, adopt nf-core modules, and change intermediate formats, as long as final outputs match. This is the goal when the pipeline is a burden you want to escape. Write the definition down and get agreement. Most migration disputes trace back to the team silently holding different definitions. ## Migrate Snakemake to Nextflow Step by Step ![Five grouped stages of the migration: freeze and inventory, translate and wire, configure profiles, run and resume, then validate and modularize.](/article-images/illustrations/migrate-snakemake-to-nextflow-step-by-step.webp) This walkthrough uses a small, realistic RNA-free example: a pipeline that aligns paired-end reads with BWA and converts SAM to BAM. The same translation pattern applies to any rule in your Snakefile. The commands assume Nextflow 24.x style DSL2. ### Step 1: Freeze and validate the Snakemake pipeline Do not migrate a moving target. Commit the current state, tag it, and prove it runs clean on test data. ```bash cd my-snake-pipeline git checkout -b nextflow-migration snakemake -n -p --cores 4 # Expected: a job list ending with a step count, no errors, for example # "Job stats: ... total: 12" ``` The `-n` flag performs a dry run, printing the planned jobs without executing them. If this fails, fix the Snakemake pipeline first. Two messages you want to see resolved before moving on: ```text MissingInputException in line 14 of Snakefile: Missing input files for rule trim: data/sampleA_R1.fastq.gz ``` This means a wildcard expansion produced a filename that does not exist. Resolve it now, because the same data assumption will otherwise surface later as a confusing channel error in Nextflow. Also run the real pipeline once end to end on test data and record checksums of the final outputs, for example with `md5sum results/**/*` redirected to a file. You will need those for parity checks in Step 8. ### Step 2: Inventory every rule and classify it List every rule with its inputs, outputs, threads, conda environment, and container directives. A spreadsheet works. Classify each rule into one of three categories, following the engineering principle of separating compute tasks from glue and adaptation tasks [3]: - **Compute tasks.** Rules that invoke a real tool: `bwa mem`, `fastp`, `bedtools`. These translate into Nextflow processes almost mechanically. - **Glue and adaptation tasks.** Rules that copy, rename, merge, or reformat files purely to satisfy the wildcard pattern of a later rule. Many of these vanish in Nextflow, because channels can restructure data inline with operators such as `map`, `collect`, and `combine`. - **Aggregation and reporting.** Rules like MultiQC or a summary table. In Nextflow these usually take a `collect` channel of upstream outputs. The glue category is where migration teams save the most code. A Snakemake project with 40 rules often has 10 or more rules that exist only to reshape files for wildcard matching. Each one you delete is one less thing to test. ### Step 3: Translate one compute rule into a process Here is a representative Snakemake rule: ```python rule bwa_mem: input: reads=["data/{sample}_R1.fastq.gz", "data/{sample}_R2.fastq.gz"], ref="refs/genome.fa" output: bam="results/aligned/{sample}.bam" threads: 8 conda: "envs/bwa.yaml" shell: "bwa mem -t {threads} {input.ref} {input.reads} | " "samtools view -b -o {output.bam}" ``` And its Nextflow DSL2 equivalent as a first pass: ```groovy nextflow.enable.dsl = 2 process BWA_MEM { tag "${meta.id}" label 'align' cpus 8 input: tuple val(meta), path(reads1), path(reads2) path reference output: tuple val(meta), path("${meta.id}.bam"), emit: bam script: """ bwa mem -t ${task.cpus} ${reference} ${reads1} ${reads2} | samtools view -b -o ${meta.id}.bam """ } ``` Notice what changed, because these are the recurring differences you will apply to every rule: - The wildcard `{sample}` became `meta.id`, a value carried alongside the files in a tuple. Nextflow does not infer sample identity from filenames. You construct the metadata map upstream, usually once, and every process downstream inherits it. - `{threads}` became `${task.cpus}`, which reads the process resource directive. This keeps the CPU count in configuration rather than in the script string. - The `conda:` environment file is gone from the process. Resource and environment selection move to `nextflow.config` and profiles, covered in Step 6. - The shell command is nearly identical. Template expressions use `${}` instead of Snakemake's `{}`. ### Step 4: Build the input channel The Snakemake rule matched samples from filenames. In Nextflow, you construct the channel that pairs reads and attaches metadata: ```groovy params { reads = "data/*_{1,2}.fastq.gz" reference = "refs/genome.fa" outdir = "results" } workflow { // fromFilePairs emits [ sample_id, [ file1, file2 ] ] read_pairs_ch = Channel.fromFilePairs(params.reads, checkIfExists: true) input_ch = read_pairs_ch.map { id, files -> meta = [id: id] return [meta, files, files[2]] } BWA_MEM(input_ch, Channel.fromPath(params.reference, checkIfExists: true)) } ``` `Channel.fromFilePairs` is the direct analogue of the two-file wildcard pattern, and `checkIfExists: true` fails fast, early, and clearly when the glob matches nothing, which replaces a whole class of late-stage Snakemake `MissingInputException` errors. The `meta` map grows over the life of a real pipeline, typically gaining fields like `single_end`, `strandness`, and `sample_type` as downstream processes need them. For richer sample sheets, most production pipelines read a CSV instead of relying on glob patterns: ```groovy meta_ch = Channel.fromPath(params.samplesheet) .splitCsv(header: true) .map { row -> [[id: row.sample, batch: row.batch], file(row.fastq_1), file(row.fastq_2)] } ``` ### Step 5: Wire the workflow and check the graph After translating every compute rule, assemble the workflow block and render the graph to confirm the topology matches your Snakefile's DAG: ```bash nextflow run main.nf -stub-run nextflow dag -f html dag.html ``` `-stub-run` executes only the `stub:` blocks of processes, if you have written them, and otherwise lets you validate channel wiring and process ordering without running real compute. A stub block for the process above looks like this, added inside `process BWA_MEM`: ```groovy stub: """ touch ${meta.id}.bam """ ``` Open `dag.html` and compare it to the DAG you exported from Snakemake (`snakemake, dag | dot -Tsvg > dag.svg`). They should be isomorphic. If Nextflow's graph is missing branches, you almost certainly have a channel that was consumed before it reached a process, or a process whose output was never connected. Fix the wiring here, on the stub run, where iteration takes seconds. ### Step 6: Move environments and resources into profiles Create a `nextflow.config` with a `params` block and profiles for each execution backend: ```groovy params { reads = "data/*_{1,2}.fastq.gz" reference = "refs/genome.fa" outdir = "results" } process { executor = 'local' withLabel: 'align' { cpus = 8 memory = 16.GB time = '4h' container = 'quay.io/biocontainers/mulled-v2-...' } } profiles { slurm { process.executor = 'slurm' process.queue = 'main' } docker { process.executor = 'local' docker.enabled = true } singularity { process.executor = 'slurm' singularity.enabled = true singularity.autoMounts = true } conda { process.executor = 'local' conda.enabled = true conda.channels = 'conda-forge,bioconda' } } ``` Two translation notes. First, Snakemake's per-rule `threads:` becomes Nextflow's per-process `cpus`, but the recommended pattern is to assign labels to processes and set resources per label in config, so cluster quotas live in one file. Second, pipelines published in the Nextflow ecosystem commonly advertise exactly this portability surface, running unchanged on local machines or HPC systems with Conda, Singularity, or Docker [4], which is what you are now replicating for your own project. A concrete structural difference to plan for: in the Snakemake rule, `bwa` and `samtools` ran in one shell command with a pipe. If your Conda environment contained both tools, that worked. In Nextflow, each process runs inside one container or one Conda environment, so a pipe across two tool images fails with `command not found` at runtime. You have two clean fixes: pick a container image that contains both tools, or split the step into a `BWA_MEM` process emitting SAM and a `SAMTOOLS_VIEW` process. Splitting is usually better, because it matches how nf-core modules are composed and lets each container stay single-purpose. ### Step 7: Run, inspect, and resume Run the real pipeline and inspect progress: ```bash nextflow run main.nf -profile docker -ansi-log false ``` `-ansi-log false` gives plain text output, which is easier to scan in logs and in CI. During the run, each process executes in a hashed directory under `work/`, for example `work/1a/2b3c4d...`. Inside you find the submitted script (`.command.sh`), the environment (`.command.run`), and captured stdout and stderr (`.command.out`, `.command.err`). When a task fails, Nextflow prints the path to this directory, and you can `cd` there and inspect exactly what ran. This is the rough equivalent of inspecting Snakemake's per-job logs, but self-contained per task. After a code change, rerun with caching: ```bash nextflow run main.nf -profile docker -resume ``` Tasks whose inputs, script text, and container are unchanged are skipped, and only affected downstream tasks rerun. Verify what was reused with the log command: ```bash nextflow log nextflow log -f status,process,exit_code,tag ``` The second command prints a table of cached versus executed tasks, so you can confirm, for example, that alignment was reused while the new QC step actually ran. Snakemake supports the same selective re-execution idea, which the workflow-management literature identifies as a core benefit of these systems [1]. The difference is that Nextflow's hash-based cache makes the boundary explicit: two tasks either have identical hashes or they do not, and `nextflow log` tells you which happened. ### Step 8: Validate parity with the Snakemake outputs Run both pipelines on the identical test inputs and frozen tool versions, then compare final outputs against the checksums you recorded in Step 1: ```bash md5sum results/**/* > nextflow.checksums diff snakemake.checksums nextflow.checksums ``` Expect exact matches for deterministic steps. For steps with nondeterministic elements, such as tools that embed timestamps or parallel reducers with unspecified ordering, compare analytically instead, for example by comparing variant sets or alignment statistics rather than file bytes. Where outputs differ, first check tool versions. Nextflow's containerization makes version drift less likely than Conda resolution drift, but only if you pin image tags rather than floating tags like `:latest`. Also run Nextflow's own configuration validation pass: ```bash nextflow config -flat ``` This prints the fully resolved configuration, which is the fastest way to catch a typo in a profile or a label selector that silently matched nothing. ### Step 9: Modularize and adopt community modules Once parity is achieved, restructure for reuse. The nf-core community maintains an extensive library of DSL2 modules and subworkflows, and the framework's recent development under DSL2 was specifically aimed at letting research communities adopt common standards progressively, as resources allow [2]. Check whether a module already exists for your tools: ```bash pip install nf-core nf-core modules list remote nf-core modules install samtools ``` Installed modules land in `modules/nf-core/...` and are imported into your workflow with `include { SAMTOOLS_VIEW; BWA_MEM } from '../modules/nf-core/...'` style statements. Replacing hand-written processes with community modules removes maintenance burden and moves your pipeline toward interfaces other teams already understand. The broader engineering argument applies here: modular ecosystems with well-defined task interfaces improve reuse and maintainability in community-driven environments [3]. If you intend your pipeline to look and behave like an nf-core pipeline, consider starting the restructured version from the nf-core template: ```bash nf-core pipelines create mypipeline ``` On older versions of nf-core/tools, the equivalent command is `nf-core create`. Note that the template imposes substantial conventions, including its own test data handling and CI, so treat it as a fresh start that you port logic into, not a wrapper around your migrated files. ### Step 10: Add tests and continuous integration Finally, add automated checks so the migration does not silently regress. The software-engineering literature on bioinformatics pipelines recommends systematic validation at three levels, environment, inputs, and runtime, plus comprehensive testing with both real and synthetic data inside continuous integration workflows [3]. Concretely for a Nextflow pipeline: - Validate the samplesheet at workflow start, rejecting missing files or duplicate sample identifiers immediately. - Keep a `-profile test` that runs the full pipeline on small bundled data in minutes, and wire it into CI on every push. - Add a parity test that compares final output checksums against known-good values for the deterministic steps. - Run the pipeline under both Docker and Singularity profiles in CI if your users span both, since environment resolution bugs often appear in only one backend. ## Common Errors and Fixes These are the errors you are most likely to hit during and shortly after migration, with the exact messages and the fix for each. **Java version mismatch at launch.** Nextflow is a JVM application, and an old runtime produces a traceback containing `UnsupportedClassVersionError`. Install a supported Java runtime for your Nextflow version and confirm with `java -version`. **Command not found inside a task.** The failure shows as `Process 'BWA_MEM' terminated with an error exit status (127)` with `command not found` in the `Command error` block. Exit status 127 means the shell could not find the executable. Almost always, the container or Conda environment selected for that process lacks the tool, often because of the piped-tools problem from Step 6. Fix by choosing an image containing every binary the script calls, or split the step. **Resource requests exceed the queue.** On a scheduler you will see a message in the form `Process requirement exceeds available CPUs, requested: 16, available: 8`. This means a process directive or its label config requests more than the scheduler node offers. Lower the label's `cpus` or target a queue with larger nodes. This commonly bites teams whose Snakemake `threads:` values were tuned for one cluster and carried over verbatim. **A channel is consumed unexpectedly.** DSL2 dataflow means a channel's contents flow to whatever consumes them. If a process receives fewer items than expected, the usual cause is that an upstream channel was already consumed by another branch, or that a value channel (a singleton) was broadcast where per-sample items were needed. The `view` operator is your diagnostic tool: insert `ch.view { "DEBUG: ${it}" }` at each junction and read the sequence. Structural fixes include re-emitting outputs from the source process with additional `emit:` declarations, or using operators such as `map`, `multiMap`, and `mix` to branch explicitly. **Missing output file after a task.** The message reads `Missing output file(s) 'X' expected by process 'Y'`. The script ran but did not create the declared output. Common causes are a filename templating typo, such as `${meta.id}.bam` versus the name the tool actually wrote, or the tool writing relative to a different working directory. Inspect the task's `work/` directory, list its contents, and reconcile the name. **Silent wildcard translation bug.** This one produces wrong results with no error, which is worse than any crash. A glob like `data/*_{1,2}.fastq.gz` that quietly matches extra files, or a `fromFilePairs` that groups an unexpected pairing, contaminates every downstream task. The defense is `checkIfExists: true`, a validated samplesheet, and the parity checksums from Step 8. **Config selectors that match nothing.** A `withLabel:` or `withName:` block with a typo applies to zero processes and Nextflow may not warn. Run `nextflow config -flat` and confirm each resource directive actually landed on the intended processes. ## Common Mistakes and Limitations These are the strategic mistakes that separate smooth migrations from painful ones. - **Migrating everything at once.** Big-bang rewrites fail for pipelines the same way they fail everywhere else. Migrate one subgraph, validate parity, run it in parallel with Snakemake for a production cycle, then move the next subgraph. - **Translating syntax one-to-one.** A Nextflow pipeline that mirrors Snakemake rule-for-rule, including every glue rule, is harder to read than either native idiom. The real win of migrating is the chance to delete glue and adopt explicit interfaces [3]. Take that win. - **Ignoring the metadata map.** Teams that pass bare file paths and rely on filename parsing inside each process recreate Snakemake's implicit coupling in a worse form. Design the `meta` map early, keep it small, and let it flow. - **Treating `work/` as an archive.** The work directory is a cache, not a results store. Publish final outputs with `publishDir` (or the `outputDir` pattern in recent versions) and treat everything else as disposable. Teams that let colleagues pull intermediate files out of `work/` create broken resumes when the cache is cleaned. - **Migrating without frozen tool versions.** If the Snakemake pipeline's Conda environments were resolved loosely, your parity check may compare different tool versions and chase phantom differences. Pin versions on both sides before comparing outputs. - **Skipping the prototype decision step.** The literature's central recommendation is to prototype on your own data before committing to a workflow manager [1]. Skipping this does not merely risk choosing the wrong tool. It also deprives the team of the small-scale Nextflow experience that makes the real migration faster. - **Expecting identical performance from day one.** Neither framework publishes head-to-head performance numbers, and wall-clock differences on your hardware and scheduler will dominate any general claim. Measure your own runs as in the prototyping step rather than trusting benchmarks from other workloads. - **Underestimating the human cost.** The largest single-line-item cost of migration is usually retraining the people who read and debug the pipeline daily. Budget time for pair-debugging sessions during the first weeks after cutover, not just for the code itself. A final limitation applies to this guide as much as to any migration plan: every pipeline is different, and the steps above are a pattern, not a script. Your wildcard topology, your scheduler quirks, and your toolset will require judgment calls that no guide can make for you. ## Frequently Asked Questions ### Is Nextflow faster than Snakemake? There is no general answer, and neither framework publishes head-to-head benchmarks. Perceived speed usually comes from resume behavior and scheduling, so benchmark both frameworks on your own data, cluster, and typical rerun patterns before drawing conclusions. ### Do I have to rewrite my entire pipeline at once? No. Migrate one representative subgraph first, validate output parity against the Snakemake version, and convert the rest incrementally while both pipelines run in parallel. ### Can I keep my Conda environments when migrating? Yes. Nextflow supports a `conda` scope that can point at your existing environment YAML files, and published Nextflow pipelines commonly support Conda alongside Docker and Singularity as execution options. ### What is DSL2 and do I need to learn it? DSL2 is Nextflow's current domain-specific language, which organizes code into modular processes and subworkflows with explicit channel connections, and it is the version the nf-core ecosystem now builds on [2]. Learn DSL2 and ignore DSL1 material, which is legacy. ### How does Nextflow resume compare to Snakemake reruns? Nextflow hashes each task's inputs, script, and container, stores results in a `work/` directory, and skips tasks with identical hashes on `-resume`. Snakemake performs incremental rebuilds based on file and code state, which is the same core capability [1], but Nextflow's hash boundary is more explicit and easier to inspect with `nextflow log`. ### Should I adopt the nf-core template for my migrated pipeline? Adopt it if you want community conventions, maintained modules, and shared testing infrastructure, since the nf-core module and subworkflow library is a major argument for Nextflow [2]. Skip it if your pipeline is small, internal, or intentionally idiosyncratic, because the template imposes significant structure. ### How do I run the migrated pipeline on an HPC cluster? Set `process.executor` to your scheduler, such as `slurm`, in a dedicated profile, assign resources through labels, and run with `nextflow run main.nf -profile slurm`. Container support through Singularity or Apptainer on the same profile gives you the portable local-and-HPC setup that published Nextflow workflows describe [4]. ### How long does a typical migration take? It depends mainly on pipeline size, wildcard complexity, and test coverage, so no single number is honest. Teams that start with a validated, frozen Snakemake pipeline and a small test dataset move far faster than teams that migrate while simultaneously fixing pre-existing bugs. ## Sources 1. [Using prototyping to choose a bioinformatics workflow management system.](https://pubmed.ncbi.nlm.nih.gov/33630841/) 2. [Empowering bioinformatics communities with Nextflow and nf-core.](https://pubmed.ncbi.nlm.nih.gov/40731283/) 3. [Software engineering for reproducible pipeline development in bioinformatics.](https://pubmed.ncbi.nlm.nih.gov/42756310/) 4. [scalepopgen: Bioinformatic Workflow Resources Implemented in Nextflow for Comprehensive Population Genomic Analyses.](https://pubmed.ncbi.nlm.nih.gov/38507648/)