Skip to content

Command Reference Patterns

This page explains what each command demonstrates from a developer perspective.

bayesmonstr2insights: Database-Driven STR App

Source: in_sight/commands/bayesmonstr2insights.py

This command demonstrates:

  • a subcommand-style CLI for multiple operations
  • database-backed metadata lookup with DuckDB
  • converting STR result records into reusable region objects
  • delegating rendering into the STR visualization workflow
  • batch visualization and HTML reporting over many STR/sample combinations

Pattern to reuse:

  • keep storage/query logic in the command layer
  • normalize region metadata before handing off to reusable workflows
  • add reporting on top of the visualization framework rather than inside it

plot2insights: Generic Front Door

Source: in_sight/commands/plot2insights.py

This command demonstrates:

  • one stable user-facing entrypoint
  • dual-mode input handling
  • BAM mode
  • CSV mode
  • layout registry backed by in_sight/r_plot.py
  • custom R script override via --r-script

Pattern to reuse:

  • build a generic command first
  • map user intent to existing internal workflows
  • keep scenario-specific logic out of the generic front door

cf2insights: Config-Driven Batch App

Source: in_sight/commands/cf2insights.py

This command demonstrates:

  • configuration-file driven workflows
  • command-line override on top of config
  • batch iteration across many mutation targets
  • report assembly using HTML templates
  • orchestration on top of in_sight/vis_flow.py

Pattern to reuse:

  • keep the base visualization primitive reusable
  • add scenario-specific parsing and reporting outside the core

scrna2insights: Table-Driven Orchestrator

Source: in_sight/commands/scrna2insights.py

This command demonstrates:

  • row-driven orchestration from a TSV
  • conversion from table rows into in_sight/str_utils.py
  • barcode/UMI aware workflows
  • delegation into in_sight/str_vis_flow_simple.py

Pattern to reuse:

  • normalize row schema
  • derive region objects
  • keep row-level orchestration in the command layer

A Practical Rule

When adding a new app, ask:

  • Is this a new front door?
  • Is this a new workflow wrapper?
  • Is this only a new layout?

Most additions should touch only one or two of those layers.