nl

research software

nevelib

GitHub

Conceptual structure

A layered library with an explicit downstream application boundary.

nevelib is organized as reusable sequence-analysis modules on top of shared infrastructure and external tool wrappers. It is meant to sit below downstream applications, not to absorb their scientific framing.

Current downstream example

nexteve-app depends on nevelib and imports selected modules and utilities, while adding its own stage orchestration and domain-specific logic.

View nexteve-app

Engineered schematic

Conceptual layers

How the package, its shared infrastructure, and external tools relate to downstream applications.

Layered schematic

Responsibility becomes more application-specific as you move upward.

  1. 01

    Downstream application layer

    Application-specific workflow logic lives above the library.

    • nexteve-app
    • Stage orchestration
    • Domain-specific thresholds and outputs
    • Research workflow semantics
    boundary
  2. 02

    nevelib module layer

    Reusable capability families exposed as focused CLIs and importable Python modules.

    • reads
    • assembly
    • search
    • clustering
    • msa
    • mapping
    boundary
  3. 03

    Shared infrastructure

    Cross-cutting utilities that keep module behavior consistent.

    • YAML config loading
    • Tool execution wrappers
    • FASTA, FASTQ, BAM helpers
    • BLAST, TSV, and PAF parsing
    boundary
  4. 04

    External executables

    Standard bioinformatics tools remain explicit runtime dependencies.

    • samtools
    • fastp
    • fastqc
    • BLAST
    • MMseqs2
    • MAFFT
    • minimap2
    • SPAdes
    • BBTools
    • mosdepth

Scope split

What belongs in the library and what does not

A practical separation that keeps the library installable and testable independently of any single downstream project.

Inside nevelib

Reusable module logic, CLI entry points, config loading, parsers, and wrappers around standard command-line tools.

  • - Module-specific entry points such as nevelib-search and nevelib-mapping
  • - Shared FASTA, FASTQ, BAM, TSV, and PAF helpers
  • - Runtime tool checking and controlled command execution

Outside nevelib

Workflow stage structure, domain-specific filtering logic, application outputs, and scientific framing for a particular downstream study.

  • - Full application orchestration
  • - Research-specific thresholds and labels
  • - Domain-level interpretation and reporting

Why this split matters

Why this structure

Focused interfaces over a monolithic pipeline.

Reuse

Common operations can be carried into new downstream tools without copying whole pipeline stages.

Testability

Module behavior can be checked in isolation before being embedded in a larger workflow.

Public precision

The site can describe the library exactly, while application pages remain scoped to their own responsibilities.

See the application boundary