MLOps DVC

The DVC engine for the MLOps hub: reproduce the training DAG, read its graph, and see which stages are out of date.

DVC is the real upstream tool — this extension manages it, it does not imitate it. dvc.yaml stays the DAG, dvc repro stays the reproduction, and the cache is DVC's.

What you can do

• Reproduce your training pipeline and have DVC skip the stages that are already up to date
• See the shape of your DAG, read straight from dvc.yaml
• Find out which stages have gone stale, and why, before you rerun anything
• Have a failed stage stop an MLOps run and name itself, instead of failing obscurely

Requirements

The MLOps extension, the desktop app, and DVC in the Python environment your workspace already uses.

Getting started

This is step 4 of the walkthrough in the MLOps extension's README, which starts from an empty folder and ends with a run that a gate stops. Install this alongside MLOps and the hub picks it up.

How it runs

The interpreter comes from Python Environments (python.env.resolve) and DVC is invoked as <interpreter> -m dvc. There is deliberately no bare dvc and no bare python3: a PATH lookup would pick a different DVC than the one the notebooks and kernels see, and a system Python refuses installs outright (PEP 668).

Install DVC with the panel's install action, or into the active environment yourself. The range this provider is written against is dvc>=3,<4, and the output parsing was measured on 3.67.1.

Capabilities

Capability	Policy	What it does
mlops.dvc.repro	medium / none	Runs dvc repro; reports which stages ran, which were cache hits, and where it stopped
mlops.dvc.dag	low / none	The DAG from dvc.yaml as nodes with dependencies
mlops.dvc.status	low / none	Which stages are stale, and why
mlops.dvc.reveal	low / none	Reveal the DVC panel

mlops.dvc.repro answers pass: false with a reason when a stage fails — that is the verdict the MLOps hub records. An unusable environment (no interpreter, no DVC, not a DVC repository) throws instead, with a different sentence for each, because each has a different fix.

Limits worth knowing

• No live log. runtime.tasks.run runs a command to completion, so a long dvc repro reports nothing until it finishes. Streaming needs a host-side seam; this is a stated v1 limit.
• Electron-only: running processes is not something a browser host does.
• One reproduction at a time — the hub enforces that; two runs share one cache.

Verification

• npm run check:dvc replays measured DVC 3.67.1 transcripts (exit 255 for a failed stage, 253 for a non-repository, the two different skip sentences, the --dot graph, status --json) through the shipped parsers.
• npm run probe:dvc -- /path/to/python builds a throwaway two-stage project and drives the same code against a live DVC: first run executes, second run is a cache hit, the graph matches dvc.yaml, a broken stage fails with its name. Re-run this after a DVC upgrade — a reworded sentence passes the harness and fails in the app.