exp show: cli table fails to parse numeric columns as expected

[dberenbaum]

Bug Report

Description

The default table format generated by dvc exp show fails to render version numbers like 2.50.0 as columns.

Reproduce

Clone https://github.com/iterative/analytics/tree/clean (note the clean branch) and run dvc exp show. None of the version number columns show (they do get rendered in other output formats like --md/--json`).

Environment information

Output of dvc doctor:

$ dvc doctor
DVC version: 2.55.1.dev20+g2a04263f0
------------------------------------
Platform: Python 3.10.10 on macOS-13.2.1-arm64-arm-64bit
Subprojects:
        dvc_data = 0.47.2
        dvc_objects = 0.21.1
        dvc_render = 0.3.1
        dvc_task = 0.2.1
        scmrepo = 1.0.2
Supports:
        azure (adlfs = 2023.1.0, knack = 0.10.1, azure-identity = 1.12.0),
        gdrive (pydrive2 = 1.15.3),
        gs (gcsfs = 2022.11.0),
        hdfs (fsspec = 2022.11.0, pyarrow = 11.0.0),
        http (aiohttp = 3.8.4, aiohttp-retry = 2.8.3),
        https (aiohttp = 3.8.4, aiohttp-retry = 2.8.3),
        oss (ossfs = 2021.8.0),
        s3 (s3fs = 2022.11.0, boto3 = 1.24.59),
        ssh (sshfs = 2023.4.1),
        webdav (webdav4 = 0.9.8),
        webdavs (webdav4 = 0.9.8),
        webhdfs (fsspec = 2022.11.0)
Config:
        Global: /Users/dave/Library/Application Support/dvc
        System: /Library/Application Support/dvc
Cache types: reflink, hardlink, symlink
Cache directory: apfs on /dev/disk3s1s1
Caches: local, s3
Remotes: s3
Workspace directory: apfs on /dev/disk3s1s1
Repo: dvc, git
Repo.site_cache_dir: /Library/Caches/dvc/repo/7f5d6fecd9ab2f28d386765a5eacb03d

[pmrowla]

I think the issue is just that the table for that repo ends up being wider than the maximum allowed width for a console table in rich (even when using the pager). The numeric columns end up being the farthest to the right, so they get cut off from the table.

I am able to see the numeric columns If I do

dvc exp show --drop Cmd

[dberenbaum]

Ah, sorry for the noise, guess I jumped to the wrong conclusion here. Thanks for taking a look @pmrowla!

Why does it still show the params and files columns at the end even when a bunch of the metrics columns get dropped?

[pmrowla]

@dberenbaum it collapses from right to left but will try to preserve at least one column of each type (metrics/params/data) whenever possible

[dberenbaum]

Looks like this has been somewhat handled on our end, but we capped at a max width of 1024 here:

https://github.com/iterative/dvc/blob/main/dvc/ui/table.py#L14

Confirmed that it works as expected by increasing that value. @skshetry What's the reason for MAX_WIDTH=1024?

[dberenbaum]

ping @skshetry

[pmrowla]

We can probably make this a bigger number, but iirc rich requires us to set some maximum value otherwise it gets confused trying to compute our table widths. I think we probably just picked 1024 because it seemed like a reasonable default at the time.

The main point here is that exp show is naive and is not really meant to be able to show tables with this many columns in it, and it would be better for users to use vscode for this instead

[dberenbaum]

With --no-pager, I get a table like this:

 ────────────────
     …    …    …
 ────────────────
     …    …    -
     …    …    -
     …    …    -
     …    …    -
     …    …    -

Not sure why we aren't showing at least one column since it would fit.

With the pager, it looks like this:

 ───────────────────────────────────────────────────────────────────────────────────────>
  Experiment                 Created        results/usage.json:monthly_cli_invocations  >
 ───────────────────────────────────────────────────────────────────────────────────────>
  workspace                  -                                                19188779  >
  main                       May 02, 2023                                      1919379  >
  ip                         May 02, 2023                                     19377657  >
  clean                      May 01, 2023                                     19188779  >
  76d1341                    May 01, 2023                                      1919379  >
  ├── aff7171 [ruddy-palp]   May 02, 2023                                      3531123  >

There's a lot of empty whitespace to the right in the table when using the pager, so I don't think it's maximizing the space. We also probably could shorten/drop the filenames, which are taking up most of the space.