This is a follow-up to #108 & #109. It takes the remaining places where we were using python -m slow_odgi.<stuff> in our testing setup and replaces them with commands we can invoke as slow_odgi <stuff>. (As a recap, this makes things work more smoothly on my machine, where the python executable is not the right one and it's surprisingly annoying to make it point to the right thing. It will hopefully avoid similar weirdness in other setups.)
It also fixes a minor problem from #109 where the new uses of slow_odgi paths required an additional argument for the paths command that wasn't present before.
Finally, to satisfy mypy, I split the graph-returning from the non-graph-returning slow_odgi functions (so they can have different return types). This way, subcommand functions that don't want to return a graph don't have to.
This is a follow-up to #108 & #109. It takes the remaining places where we were using
python -m slow_odgi.<stuff>in our testing setup and replaces them with commands we can invoke asslow_odgi <stuff>. (As a recap, this makes things work more smoothly on my machine, where thepythonexecutable is not the right one and it's surprisingly annoying to make it point to the right thing. It will hopefully avoid similar weirdness in other setups.)It also fixes a minor problem from #109 where the new uses of
slow_odgi pathsrequired an additional argument for thepathscommand that wasn't present before.Finally, to satisfy mypy, I split the graph-returning from the non-graph-returning
slow_odgifunctions (so they can have different return types). This way, subcommand functions that don't want to return a graph don't have to.