This is purely a quality-of-life thing, but it would be cool to make a top-level CLI entry point for the slow-odgi commands. In particular, what is currently python3 slow_odgi/flip.py could become slow-odgi flip, i.e., we'd make an installable executable called slow-odgi with several subcommands.
The concrete steps for this would be:
Add an __init__.py to the slow_odgi directory to make it into a Python package.
Adjust the imports in slow_odgi/*.py to use package-relative imports. For example, use from . import mygfa instead of import mygfa.
Somewhere (in __init__.py or a new __main__.py), make a new main function that dispatches to all of the various algorithms. argparse supports subcommands; we could also try Click instead.
Add metadata to make the slow_odgi package installable (with an executable). As you probably know, my favorite tool for this is Flit, but there are other options available.
Probably best to ignore this until after #29 and #31 are merged.
Going to wait until #48 lands, since the changes proposed here will create a large diff and create further opportunities for tidying! Those may clash with the cleanup of 48.
This is purely a quality-of-life thing, but it would be cool to make a top-level CLI entry point for the
slow-odgi
commands. In particular, what is currentlypython3 slow_odgi/flip.py
could becomeslow-odgi flip
, i.e., we'd make an installable executable calledslow-odgi
with several subcommands.The concrete steps for this would be:
__init__.py
to theslow_odgi
directory to make it into a Python package.slow_odgi/*.py
to use package-relative imports. For example, usefrom . import mygfa
instead ofimport mygfa
.__init__.py
or a new__main__.py
), make a new main function that dispatches to all of the various algorithms. argparse supports subcommands; we could also try Click instead.slow_odgi
package installable (with an executable). As you probably know, my favorite tool for this is Flit, but there are other options available.Probably best to ignore this until after #29 and #31 are merged.