iterative
exp show: cli table fails to parse numeric columns as expected
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
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
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?
@dberenbaum it collapses from right to left but will try to preserve at least one column of each type (metrics/params/data) whenever possible
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?
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
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.