v0.2.60
WHERE THE PARENT LANDS
Four findings from the founder's own Arabian Shield project, run purely on DVT, each closed by a rule rather than a patch. A view over a federated model on the default target was being pulled into federation and rebuilt as a table; the founder's rule is dbt's: a dependent of a model that lands on the default target is an ordinary model with a parent that exists there, and dbt builds it. Only a parent that lands on another connection pulls its dependents along. When a federated load meets a view standing at its name, DVT now does what dbt's own materialization does — asks the adapter what stands there and drops it through the adapter — rather than any per-engine catalog logic. dvt parse on an environment that has not been synced says so in one line and names the fix, before dbt runs, instead of a forty-line traceback. And DVT has its own manifest now: target/dvt_manifest.json carries the engine stamps, connections and the real database of every source bound elsewhere, while dbt's manifest.json is left byte-for-byte dbt's so every dbt tool keeps working; the served catalog reads DVT's view. Linux arm64 wheels join the release, built on GitHub's native arm64 runner.
FIXED
- ▸A view (or table, or incremental) reading a federated model on the default target was coerced into a federated table, so a plain view over an f_table came back as a table and failed when its own earlier view stood at the name. Dependents of an unpinned federated model now stay native and run in dbt's phase after DVT's; only a parent pinned to another connection, or a foreign source, pulls a model into federation.
- ▸A federated load whose landing name held a view (built by a native run) died on the loader's own drop table on every engine. dvt run now asks each output's dbt adapter what stands at every landing name before DVT's phase and drops a non-table through the adapter, exactly as dbt's table materialization does; dvt sync installs the macro, and dvt run refreshes it when it is missing.
- ▸dvt parse on an environment that had not been synced printed dbt's 'No module named' error and a forty-line traceback out of dbt's profile loader before DVT's pointer at dvt sync. Parse now checks, before dbt runs, that this environment can load the adapter of every output the profile declares, and refuses a missing one in a single line that names the adapter and the fix.
- ▸The catalog's source pages showed neither a bound source's real database nor its connection: docs generate had stamped DVT's fields into dbt's manifest.json, the next dvt run had dbt rewrite that file, and a source on another connection carried the default target's database. DVT now writes its own target/dvt_manifest.json and leaves dbt's manifest byte-for-byte dbt's, so every dbt tool keeps working; the served catalog reads DVT's view of the current manifest, and a source page lists Source, Database, Schema, Table and Connection.
ADDED
- ▸Linux arm64 (aarch64) wheels for Python 3.10 to 3.14, built natively on GitHub's arm64 Linux runner: Graviton and Ampere hosts and linux/arm64 containers can pip install dvt-core.
Get it: pip install dvt-core==0.2.60 · wheels on PyPI for macOS (arm64 + x86_64) and Linux x86_64, Python 3.10–3.14 — the full platform matrix.