Closed prisae closed 1 year ago
Merging #86 (a359433) into main (65f2667) will decrease coverage by
0.98%
. The diff coverage is75.00%
.:exclamation: Current head a359433 differs from pull request most recent head 7940dfd. Consider uploading reports for the commit 7940dfd to get more accurate results
@@ Coverage Diff @@
## main #86 +/- ##
==========================================
- Coverage 86.59% 85.61% -0.99%
==========================================
Files 4 5 +1
Lines 388 424 +36
==========================================
+ Hits 336 363 +27
- Misses 52 61 +9
Using the CLI you can really see the improvement made by #85
Without faster-import
WITH faster-import
It obviously still has some cost, what we can see when comparing it to starting python with a plain print
-statement:
I'm generally in favor of adding this, though I'd like to see it do a few more things (happy to help implement):
Report
subclass from a downstream package. I think it'd be useful to have scooby look for a Report
class at the top level namespace of a package so that something like scooby --report pyvista
would yield pyvista.Report()
scooby django-*
and get a list of all the django-*
packages like django-allauth
, etc. This would be analogous to pip list | grep django-
scooby --track foo.py
which would use tracking features to output a tracked report after completion.I implemented your suggestion (1), and simplified the whole CLI to a single file.
You might have to have a look at (2) and (3), as you did the tracker that might be faster. However, we might also just merge what we have, and add additional options to the CLI as we have time.
as another minor comment, main
is turning into a bit of a beast. I tend to split the command line parsing out into its own function, e.g.:
def parseargs(argv):
parser = ArgumentParser()
# ...
args = parser.parse_args(argv or sys.argv[1:])
if args.version:
print(f"scooby v{scooby.__version__}")
sys.exit()
return args
I also tend to use the Namespace
object rather than converting to a dict
, never seen that, but docs do mention that even if all the examples there leave it in object form.
I agree that __main__
got bigger than intended, because things got added (as always). I usually also use an own parser function. Here, in this case, I don't really mind either way. Same regarding Namespace
vs dict
.
What are your opinions @banesullivan , @akaszynski ?
+1 for splitting the command line parsing out into its own function.
Re Namespace
vs dict
... I'm not sure I follow...
@prisae, I'm happy with this in it's current state, so feel free to merge (and bump the version) when you feel it is ready
I split it into a parser function and a function that acts upon it.
I left it as dict. I am simply used to that way, particularly as I can provide that dict, in some other cases, directly as kwargs to the subsequent functions.
Brining this in, thanks @smason for all the feedback and inputs!
I forgot to add the entry_point
to the conda-forge feedstock, so the CLI won't work on Windows when installed through conda.
https://github.com/conda-forge/scooby-feedstock/pull/22 is fixing this.
Command-line interface CLI
Initial implementation - very basic, no tests so far. I am more interested to know first if you are interested in this at all (@banesullivan, @akaszynski).
What you can do currently in a terminal:
Print the default scooby-report
Print only the version of scooby
Print the help
Print any number of packages (they are added to the
additional
list)Also implemented is the
sort
-flag. It is false by default (just as in the Python interface), and if you specify it it will be set to true.The implementation is quite flexible and works for:
scooby
folder (that is the reason for thescooby/__main__.py
-file)scooby.__main__.py
Although, frankly, only (1) is of general interest. (2) and (3) can be useful when developing or testing.
TODO's
conda
-recipe needs updating