Argparse for argument handling

[Psy-Fer]

Hey Sebastian,

Really cool work mate.

I have found argparse to be super helpful in handling arguments to cli tools, with well structured --help, required, grouped, and mutually exclusive args,

Here is an example from one of my single file python repos from a few years back, that looked at amplicon coverage across viral genomes.
https://github.com/Psy-Fer/CoVarPlot/blob/main/covarplot.py

So this would replace your current sys.argv[1:] arg handling, and formalise the short(-)/long(--) args.

A say this as someone who spend years using sys.argv before switching myself, but can confirm, it's solid, and part of the core python standard libs.

Cheers,
James

[Psy-Fer]

Here is a much more complicated CLI using argparse, where I maintain 2 different CLI's depending on the version of imported libraries being used (basically guppy vs dorado for ONT basecalling and all the breaking changes between them)

https://github.com/Psy-Fer/buttery-eel/blob/main/src/buttery_eel/cli.py

Just to show some of the capability

[ATinyGreenCell]

Hi @Psy-Fer — Claude here writing on Seb's behalf.

You're right that argparse is the better long-term home for the CLI. SpliceCraft's main() is currently doing manual sys.argv[1:] scanning with five separate in-place mutations (--no-splash, --agent-api, --agent-api-port=N, the positional file arg, etc.) — every new flag piles another shape onto that mess, and --help is hand-rolled.

The buttery-eel example is a good model — it's the same pattern Seb would want here (mutually-exclusive groups for --check / --dry-run / --restore-pre-update under the update subcommand, required-but-conditional under agent-api, etc.).

Honest answer about timing: Seb has v1.0.0 gated on a SnapGene round-trip implementation, and an argparse migration is invasive enough that it shouldn't happen in the same release window — main() is the most-tested entry point in the suite and the test fixtures all hand-construct sys.argv lists. It's the kind of refactor that wants its own release with its own test pass, not bundled with feature work.

So: filing this as a tracked v1.0-prep item. Seb agrees with the proposal; the holdup is purely sequencing. When he picks it up, the buttery-eel pattern is what'll guide the layout.

Thanks for the well-pitched suggestion — and for the second example showing the conditional-import dance, that's exactly the kind of thing the update path will benefit from.