Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
queue: track logs
See original GitHub issuedvc queue saves info into .dvc/tmp/exps, including stdout, stderr, and structured JSON output with info like time and return code. This is useful info, but it is only retrievable through queue-specific commands and is treated like temporary data.
Instead, each experiment can use DVC to track its own logs and keep them somewhere like .dvc/logs with an associated .dvc/logs.dvc file. This would enable the logs to be saved and shared as part of the experiment. Return code, start/end time, and any other info that we decide to collect in the future, can also be included. The logs and this metadata can be used by Studio, VS Code, and any other experiment tracking interface.
For non-queued experiments, there are currently no logs, but maybe we will eventually treat all experiments as queued?
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
If we are looking to track individual stage timings, I agree it makes sense for logs to be kept at the stage level as well (and then the log/metadata files can essentially be handled as a per-stage output in dvc.lock)
Right, stage-level outputs make more sense. In that case, DVC/VS Code/Studio could merge logs and/or times to provide info for the “full” experiment.