DVT DEPS, CLONE & RETRY

DVT DEPS — INSTALL YOUR PROJECT'S PACKAGES

Reads packages.yml, resolves versions, and installs everything into dbt_packages/ — exactly as you know it:

$ dvt deps
14:20:01  Installing dbt-labs/dbt_utils
14:20:02  Installed from version 1.3.0
14:20:02  Up to date!
14:20:02  Installing calogica/dbt_expectations
14:20:03  Installed from version 0.10.4
14:20:03  Up to date!

Your existing packages.yml works unchanged — hub packages with version ranges, git packages pinned to a revision, local packages by path:

# packages.yml — the same file, the same syntax
packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.0.0", "<2.0.0"]
  - git: "https://github.com/your-org/internal-macros.git"
    revision: v0.4.2
  - local: ../shared_macros

The resolution is pinned in package-lock.yml, so CI installs exactly what you installed. --add-package does the add-and-install in one step:

$ dvt deps --add-package dbt-labs/dbt_utils@1.3.0

dbt_packages/ is disposable by design — dvt clean sweeps it with the rest of your clean-targets, and the next dvt deps brings it back from the lock file.

DVT CLONE — COPY ANOTHER ENVIRONMENT'S RELATIONS INTO THIS ONE

Clone takes the manifest from a previous run — usually a prod job's artifacts, downloaded from CI — and recreates the relations it records in your current target, without rebuilding anything. Point --state at the artifacts directory:

$ dvt clone --state prod-artifacts --select stg_orders+
14:31:08  Concurrency: 4 threads (target='dev')
14:31:08
14:31:09  1 of 3 START clone of analytics.stg_orders ................................... [RUN]
14:31:09  2 of 3 START clone of analytics.orders_enriched .............................. [RUN]
14:31:09  3 of 3 START clone of analytics.customer_ltv ................................. [RUN]
14:31:09  1 of 3 OK cloned analytics.stg_orders ........................................ [CREATE VIEW in 0.21s]
14:31:10  2 of 3 OK cloned analytics.orders_enriched ................................... [CREATE VIEW in 0.34s]
14:31:10  3 of 3 OK cloned analytics.customer_ltv ...................................... [CREATE VIEW in 0.29s]
14:31:10
14:31:10  Finished running 3 clones in 0 hours 0 minutes and 1.82 seconds (1.82s).
14:31:10
14:31:10  Done. PASS=3 WARN=0 ERROR=0 SKIP=0 TOTAL=3

The classic use is seeding a dev schema: clone prod's relations in seconds, then develop against them — a --defer workflow with something real to defer to. Leave the selection off to clone everything the manifest records, or use the selection syntax you already know to take just a slice.

One caveat worth knowing before you rely on it: what a clone physically is depends on the engine. Warehouses with native zero-copy clone give you a true independent copy. Engines without it — DuckDB, the default target dvt init scaffolds, included — get a pointer viewover the source relation instead (that's the CREATE VIEW in the output above). It answers queries fine, but it follows the source as it changes and breaks if the source is dropped. Perfect for the defer workflow; never a backup.

DVT RETRY — RE-RUN ONLY WHAT FAILED

When a run fails partway, retry picks up where it stopped: nodes that failed — and everything skipped downstream of them — run again, and nodes that already passed are left alone. Say a nine-model run loses one model and the two below it:

$ dvt run
    ...
14:44:09  Completed with 1 error, 0 partial successes, and 0 warnings:
14:44:09
14:44:09  Database Error in model orders_enriched (models/marts/orders_enriched.sql)
  column "order_ts" does not exist
14:44:09
14:44:09  Done. PASS=6 WARN=0 ERROR=1 SKIP=2 TOTAL=9

Fix the failing model first — the run's own state file remembers what failed, so there's nothing else to tell it:

$ dvt retry
14:46:02  Concurrency: 4 threads (target='dev')
14:46:02
14:46:02  1 of 3 START sql table model analytics.orders_enriched ....................... [RUN]
14:46:03  1 of 3 OK created sql table model analytics.orders_enriched .................. [SELECT 12840 in 0.94s]
14:46:03  2 of 3 START sql view model analytics.orders_by_region ....................... [RUN]
14:46:03  3 of 3 START sql table model analytics.customer_ltv .......................... [RUN]
14:46:04  2 of 3 OK created sql view model analytics.orders_by_region .................. [CREATE VIEW in 0.31s]
14:46:04  3 of 3 OK created sql table model analytics.customer_ltv ..................... [SELECT 4102 in 0.88s]
14:46:04
14:46:04  Finished running 3 models in 0 hours 0 minutes and 2.20 seconds (2.20s).
14:46:04
14:46:04  Completed successfully
14:46:04
14:46:04  Done. PASS=3 WARN=0 ERROR=0 SKIP=0 TOTAL=3

TOTAL=3, not 9 — the six models that passed weren't touched. Retry repeats whichever verb ran last (run, build, test, seed, snapshot) with the flags it ran with, so a long build that died at model 40 of 200 resumes at 40 instead of starting over. From outside the project, dvt retry --project-dir app works the way it does everywhere else.

REFERENCE — THE FLAGS

All three verbs take the engine-wide flags you already use — selection (-s/--select, --exclude, --selector), --project-dir, --profiles-dir, -t/--target, --threads, --vars, the logging family — with their usual spellings and meanings. What follows is only what each verb adds.

dvt deps

dvt clone

dvt retry

Retry adds no flags of its own — the previous run's own state is the input, so there's nothing to configure. Of the engine-wide set, the ones you'll actually reach for are --project-dir (retry from outside the project), --threads and -x/--fail-fast.