exp show: customize rich table rendering behavior

[pmrowla]

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

Thank you for the contribution - we'll try to review it as soon as possible. 🙏

Will close #5247

• Updates rich version to 9.x, uses native rich pager support
• Re-enables color/styling in exp show table
• When using --no-pager, columns will be collapsed in right-to-left order if the table cannot fit into the console
  • At least one metric column and one params column will always be displayed whenever possible.
  • Params will be collapsed before metrics
  • If the table still does not fit after collapsing all but one metric and param column, will fallback to rich's folding behavior for the remaining columns

TODO

• Wrap rich column/table classes to collapse/merge metrics & params columns which can't be displayed due to terminal width

[pmrowla]

Collapse behavior example using jameson-metrics:

current master:

$ dvc exp show --no-pager
┏━━━━━━━━━━━━┳━┳━━━━━━━━━┳━━━━━┳━━━━━┳━━━━━━━━┳━━━━━━━━━┳━┳━┳━┳━┳━┳━┳
┃ Experiment ┃ ┃     AUC ┃  TP ┃  TN ┃   took ┃    loss ┃ ┃ ┃ ┃ ┃ ┃ ┃
┡━━━━━━━━━━━━╇━╇━━━━━━━━━╇━━━━━╇━━━━━╇━━━━━━━━╇━━━━━━━━━╇━╇━╇━╇━╇━╇━╇
│ workspace  │ │ 0.75265 │ 190 │ 894 │ 206.43 │ 0.85513 │ │ │ │ │ │ │
│ master     │ │ 0.75265 │ 190 │ 894 │ 206.43 │ 0.85513 │ │ │ │ │ │ │
└────────────┴─┴─────────┴─────┴─────┴────────┴─────────┴─┴─┴─┴─┴─┴─┴

after this PR:

$ dvc exp show --no-pager
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━┳━━━━━┳━━━┳━━━━━━━━┳━━━┓
┃ Experiment ┃ Created      ┃     AUC ┃  TP ┃  TN ┃ … ┃ L4size ┃ … ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━╇━━━━━╇━━━╇━━━━━━━━╇━━━┩
│ workspace  │ -            │ 0.75265 │ 190 │ 894 │ … │ 24     │ … │
│ master     │ Feb 29, 2020 │ 0.75265 │ 190 │ 894 │ … │ 24     │ … │
└────────────┴──────────────┴─────────┴─────┴─────┴───┴────────┴───┘

@dmpetrov @dberenbaum does this work for collapsing the --no-pager table to fit terminal width?

[dberenbaum]

@pmrowla I like your idea to show the first listed metrics and parameters rather than let rich decide, and as you mentioned, maybe the first metric should even be on the right to be next to the first parameter and consistent with viewer.

A couple small suggestions to try (interested in feedback on whether others find these useful @pmrowla @dmpetrov @skshetry):

• Provide a hint above or below the table with something like: 6 of 14 columns shown. Use --include-metrics/--include-params to specify which columns to show.
• A suggestion from #8 in https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46 is: "Never output table borders. It’s noisy and a huge pain for parsing." This would at least solve the issue of the empty columns:

  Experiment   Created            AUC    TP    TN     L4size    

  workspace    -              0.75265   190   894     24        
  master       Feb 29, 2020   0.75265   190   894     24        

One bigger suggestion is to provide a csv or tsv output option for a few reasons:

• Users likely will have no problem reading csv files into other tools and formatting, sorting, and visualizing however they want, giving users more flexibility and making it less necessary to solve all those issues in cli output.
• Number of columns does not need to be limited to screen width, so the leftmost column that summarizes a complex tree structure can be expanded into multiple columns, one for each level of the tree (and probably at least one additional one for checkpoints). Even rows that are mostly empty are fine, so more info can be provided by adding columns.
• Provides an easily parseable serialization format for saving, sharing, etc.

[pmrowla]

• A suggestion from Documentation is needed #8 in https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46 is: "Never output table borders. It’s noisy and a huge pain for parsing." This would at least solve the issue of the empty columns:

This seems a bit more personal preference? Not having borders makes it harder to read bigger tables imo, but I don't have any strong opinions about it either way.

I do think that we shouldn't worry about making the table machine-parsable though. If users want machine readable data they should just be using a better output format like json (or potentially csv).

[pmrowla]

Will update table class location once #5348 is merged