Misc. updates#1881
Conversation
| This type of metrics files are created by users, or generated by user data | ||
| processing code, and get defined with the `-p` (`--plots`) and | ||
| `--plots-no-cache`) options of `dvc run`. `dvc plots` subcommands can work with | ||
| plots files committed to a Git repo history, data files controlled by DVC, or | ||
| any other file in system. | ||
| processing code, and can be defined in `dvc.yaml` stages (using the `--plots` | ||
| and `--plots-no-cache` options if using `dvc run`). `dvc plots show` and | ||
| `dvc plots diff` can work with any valid plots files in the system, whether | ||
| tracked by Git or DVC, or not. |
There was a problem hiding this comment.
Finishes #1800 @pared @shcheklein but note that since plots modify does require that plots are defined in dvc.yaml, I couldn't change this to be as general as suggested initially (summarized in #1809 (comment)):
if we explain in the plots concept itself that plots are not only dvc.yaml based people won't expect dvc.yaml to be present in the first place.
There was a problem hiding this comment.
I like the shift from get defined to can be defined. This is on point what we actually did.
can work with any valid plots files in the system
While it is something we need to do (as part of treeverse/dvc#4446, currently we cannot dvc plots show {target} in no-repo case, as we will get error that '.' is not a git repo.
There was a problem hiding this comment.
OK great, thanks for addressing that. In that case we can leave this text as-is, I think.
There was a problem hiding this comment.
I think we are still overcomplicating this. In this doc the most important points to say that users can output certain type of metrics (arrays, etc) into JSON, YAML or whatnot and DVC provides a bunch of commands to deal with them - visualize, compare, etc, etc. We should def mention that it is similar to metrics, but for "continuous", etc, etc
Details that certain commands require dvc.yaml to be present can be hidden into those commands. Or there should be a separate section that starts with some motivation for creating a dvc.yaml- what benefits on top of regular files people can get from using it.
There was a problem hiding this comment.
Well, I was following the original idea to emphasize that plots don't have to be tracked by DVC... But you're right, this was too low level for an index. I just removed a bunch of redundant info and left the basics + some refs to where the details are. Also updated show and diff a bit again. See 27519b4.
3 participants
repro --pullper docs: repro: add --pull #1841 (review)plotssubcommands work with any valid plots files in the system per plots and metrics: update new targets rules #1809 (comment) (closes plots: update docs #1800)dvc status -c/rsample outputs (see docs: update cloud status #1877 (review))