Closed dberenbaum closed 9 months ago
The only thing to consider is that we need to add it as a pipeline output, which I don't think is a bad idea. We can either do -o eval
for the entire dir or -o eval/plots
and we could either add or leave out -O eval/metrics.json
. My bias is to track all the outputs rather than leave some out; it's easier to explain and keeps the metrics tied to the model training.
Check also if we need to pass report=None
https://github.com/iterative/example-repos-dev/pull/248#discussion_r1314899146
Check also if we need to pass
report=None
#248 (comment)
Since we don't use the context manager and instead explicitly call live.make_dvcyaml()
, I don't think it should be an issue (cc @daavoo). live.make_report()
isn't being implicitly called anywhere AFAICT. Also https://github.com/iterative/dvclive/pull/684 would make report=None
the default so this seems like a very short-term problem.
Check also if we need to pass
report=None
#248 (comment)Since we don't use the context manager and instead explicitly call
live.make_dvcyaml()
, I don't think it should be an issue (cc @daavoo).live.make_report()
isn't being implicitly called anywhere AFAICT.
Context manager is used:
I guess it was just not deployed yet
🤦 I must have looked on my phone or something and completely missed the changes to evaluate.py
in that PR. Closing this issue.
We could open a separate one to set report=None
, but it's likely a short-term problem as explained above.
Still seems like the pipeline fails to cache the images, though, right?
do
-o eval
for the entire dir
I increasingly feel this would be the best default for dvclive, both with and without pipelines. It requires a DVC remote, but I think it's needed in almost every real scenario, and Git-only workflows are likely not helping with onboarding since I have found most people are confused by the idea of tracking dvclive
with Git. Caching all of dvclive
simplifies the workflow. Without pipelines, it's easy to log any size files and know that everything logged by dvclive is saved in the same place. With pipelines, it makes the stage definition simple since you just add dvclive
as a stage output.
btw, we could try to utilize .dvcignore
to "ignore" the dvc.yaml
inside the eval
/ dvclive
dir?
I haven't had time to react to the PR review and push the repo, folks. Yes, I also saw that CI failed. I'll try to take a look today.
For this repo specifically, I wanted to have a mix tbh - some metrics in Git, some outside (this repo is more than just experiments).
But may be you are right, Dave and we should just track the whole directory there.
btw, we could try to utilize
.dvcignore
to "ignore" thedvc.yaml
inside theeval
/dvclive
dir?
No, it doesn't help unfortunately. I tried it when iterating on https://github.com/iterative/dvclive/issues/456.
For this repo specifically, I wanted to have a mix tbh - some metrics in Git, some outside (this repo is more than just experiments).
What is the benefit at this point? I think seeing the metrics in Git is a very limited benefit these days (mostly I expect people use vs code/studio/cli to see metrics) and some users have complained about the noise it generates.
I haven't had time to react to the PR review and push the repo, folks. Yes, I also saw that CI failed. I'll try to take a look today.
I don't think it's worth spending time on it until we decide on this discussion since it likely has to change to cache the images inside the pipeline.
What is the benefit at this point?
Primarily for demoing things.
E.g. A simple file like metrics.json
- could use GH/GL interface to diff things. You could create a CI action w/o setting up AWS credentials (annoying and 10x complicated).
We could keep an option to disable the cache and make it apply to the entire dir for those kinds of scenarios
So, what's your take? What should we use as a default? All remote, one single dir?
I can try to update the repo today ...
Yes, that's my take. WDYT? I'm wondering if we should also cache everything without pipelines by default in dvclive 3.0.
Originally from https://github.com/iterative/example-repos-dev/pull/248#issue-1876465827