New CLI functionalities: tree, report, job info

[gpetretto]

Some new functionalities for the CLI:

• To hopefully help new users explore the functionalities of the CLI, I have added a jf tree command. This prints a tree with the all the commands available. Can optionally control the depth of the tree, choose the starting point, show also the options for each command and the docstring for each branch of the tree. I thought it may be useful to have a quick bird-eye view if one is searching a specific command.
• A new functionality to get a summary report of the state of the Jobs and Flows in the DB. Modeled on the report from Fireworks, can summarize the current number of jobs in different states and trends over time. Commands: jf job report, jf flow report.
• Previously jf job info printed the content of JobInfo (or JobDoc) in alphabetical order. Now the order is predetermined, keeping close entried that are related to each other (e.g. all the dates).

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 89.60245% with 34 lines in your changes missing coverage. Please review.

Project coverage is 72.28%. Comparing base (c9d5d87) to head (a7c8005).

Files with missing lines	Patch %	Lines
src/jobflow_remote/cli/utils.py	60.00%	16 Missing and 4 partials ⚠️
src/jobflow_remote/jobs/jobcontroller.py	90.00%	3 Missing and 2 partials ⚠️
src/jobflow_remote/cli/formatting.py	95.83%	2 Missing and 2 partials ⚠️
src/jobflow_remote/jobs/report.py	97.61%	1 Missing and 1 partial ⚠️
src/jobflow_remote/utils/data.py	88.23%	1 Missing and 1 partial ⚠️
src/jobflow_remote/cli/jfr_typer.py	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop     #180       +/-   ##
============================================
+ Coverage    47.99%   72.28%   +24.28%     
============================================
  Files           44       45        +1     
  Lines         5353     5671      +318     
  Branches       848      890       +42     
============================================
+ Hits          2569     4099     +1530     
+ Misses        2534     1260     -1274     
- Partials       250      312       +62     

Files with missing lines	Coverage Δ
src/jobflow_remote/cli/flow.py	72.11% <100.00%> (+48.95%)	⬆️
src/jobflow_remote/cli/jf.py	87.50% <100.00%> (+13.30%)	⬆️
src/jobflow_remote/cli/job.py	82.22% <100.00%> (+61.36%)	⬆️
src/jobflow_remote/cli/project.py	75.57% <100.00%> (+32.82%)	⬆️
src/jobflow_remote/cli/types.py	100.00% <100.00%> (+3.70%)	⬆️
src/jobflow_remote/cli/jfr_typer.py	92.85% <80.00%> (-2.80%)	⬇️
src/jobflow_remote/jobs/report.py	97.61% <97.61%> (ø)
src/jobflow_remote/utils/data.py	65.16% <88.23%> (+6.83%)	⬆️
src/jobflow_remote/cli/formatting.py	85.82% <95.83%> (+75.04%)	⬆️
src/jobflow_remote/jobs/jobcontroller.py	79.22% <90.00%> (+44.29%)	⬆️
... and 1 more

... and 19 files with indirect coverage changes

[gpetretto]

Also fixed the coverage report. From a few tests it seemed that running with --cov-append was not really working. Basically just sending to codecov the report from the integration tests. Sorry @ml-evs, do you see any issue with the changes in.github/workflows/testing.yml?

[ml-evs]

Also fixed the coverage report. From a few tests it seemed that running with --cov-append was not really working. Basically just sending to codecov the report from the integration tests. Sorry @ml-evs, do you see any issue with the changes in.github/workflows/testing.yml?

Hi @gpetretto, no issue from my side (especially as the number has gone up!) I'm surprised its not working given that the config was just taken from a project that does the same thing successfully, the only difference I can see is that the flag --cov=./optimade specifies a directory in my case, rather than a package name (though both should be supported). I can quickly open a PR for my own curiosity that checks if this is the issue, otherwise your approach looks robust to me!

Do you want me to take a look at the rest of the PR at all? I'm still fighting with SGE in #160...

[gpetretto]

Hi @gpetretto, no issue from my side (especially as the number has gone up!) I'm surprised its not working given that the config was just taken from a project that does the same thing successfully, the only difference I can see is that the flag --cov=./optimade specifies a directory in my case, rather than a package name (though both should be supported). I can quickly open a PR for my own curiosity that checks if this is the issue, otherwise your approach looks robust to me!

Do you want me to take a look at the rest of the PR at all? I'm still fighting with SGE in #160...

Thanks for the tests on the coverage. For the review, I am not sure if @davidwaroquiers already started looking at this.

[davidwaroquiers]

Thanks a lot for this! Not sure I'll have the time to review this soon enough (most probably not before next week). I could still already test the report, which is really nice! My only comments right now maybe would be about the tree command. I like the idea because we've had many people saying "oh, the jf command line interface has many options and it's difficult to find your way in it". That definitely helps! Would it be possible to put a small description of each of the commands also on the right (could it be taken from the help of each of the commands ? maybe it's too long? or maybe it would be too much anyway ?). My other comment is actually about having as a command itself. Wouldn't it be "better" to have it as an option ? e.g. jf --tree prints the entire tree, jf job --tree prints the tree starting at jf job, etc ... What do you think ?

[gpetretto]

Thanks a lot for this! Not sure I'll have the time to review this soon enough (most probably not before next week). I could still already test the report, which is really nice! My only comments right now maybe would be about the tree command. I like the idea because we've had many people saying "oh, the jf command line interface has many options and it's difficult to find your way in it". That definitely helps! Would it be possible to put a small description of each of the commands also on the right (could it be taken from the help of each of the commands ? maybe it's too long? or maybe it would be too much anyway ?). My other comment is actually about having as a command itself. Wouldn't it be "better" to have it as an option ? e.g. jf --tree prints the entire tree, jf job --tree prints the tree starting at jf job, etc ... What do you think ?

For the first point, this should be already addressed. If you run jf tree -D you should also get the docstrings for all the entries that are shown.

Making it as an option instead of a command will be somewhat trickier to implement, but not too much. I may need to manually create a function for each of the subcommands. It should be easier to have it as an additional command for all the subcommands. e.g. jf tree, jf job tree, jf job set tree. I considered this option, but then it means that when you plot the full tree, you get all the tree commands in it, one for each subcommand, which makes it less readable.
If you think the --tree option is right way to go it can be implemented though. Maybe there is a way to add it to all the subcommands.

[davidwaroquiers]

Or directly in the help ? Is there a verbosity for help ?

-h -v could give the tree for example

[gpetretto]

Tthe --help option is generated automatically by typer. I think it may be possible to override it and complement it with the -v, but I don't think it will be any faster than the --tree. Probably more involved.

[davidwaroquiers]

I think the --tree would be better if it's not too much work. I would guess it would be possible (and maybe relatively easy ?) to add something in your JFRTyper class so that the --tree option is automatically added to all commands and subcommands. What do you think ?

[gpetretto]

One additional problem I have thought about with the --tree option is that I currently defined several options for the tree command: show the hidden commands, show the documentation, show the options, depth of the tree to display. Having these as additional options to each of the commands will probably both be confusing, as they actually apply to the tree and not to the command itself, and will likely bloat the help of all the commands with information that is not so important. So I propose to either use the --tree option, but then just show the tree without any option to customize what can be shown, or stick to the tree command. In the latter case, if it is preferable, it can be that tree is defined for each subcommand so to have something like jf job tree instead of the jf tree job, that is currently implemented now.

[davidwaroquiers]

One additional problem I have thought about with the --tree option is that I currently defined several options for the tree command: show the hidden commands, show the documentation, show the options, depth of the tree to display. Having these as additional options to each of the commands will probably both be confusing, as they actually apply to the tree and not to the command itself, and will likely bloat the help of all the commands with information that is not so important. So I propose to either use the --tree option, but then just show the tree without any option to customize what can be shown, or stick to the tree command. In the latter case, if it is preferable, it can be that tree is defined for each subcommand so to have something like jf job tree instead of the jf tree job, that is currently implemented now.

Indeed. I would probably still go with the --tree, in which documentation and options are always shown, and we don't show the hidden commands (hidden commands are for admins/developers so they should be able to find out in either the documentation or the code, what do you think ?). I would say for the depth, we can drop it. What do you think ?

[gpetretto]

I would say that showing documentation and options for all the tree basically defeats the purpose of the command, that is to give a quick overview of the commands available.
Except for the lower levels of the tree, where it just becomes equivalent to jf xxx -h, it will just print an unreadable wall of text which can be several pages long. I would still prefer the command, but if going with the --tree option I would really not put anything else other than the list of subcommands.

[gpetretto]

Following internal discussion the tree command has been switched to a --tree option for jf and all the subcommands. It shows the tree and the first line of the documentation of the commands. All the options are still left implemented to potentially change visualization in the future.

[davidwaroquiers]

All good to me! Great work!