dbt deps warns but keeps the first duplicate package

Two entries in a dbt dependency file can resolve to the same project name even when they came from different sources. A new dbt v2 issue says dbt deps currently retains the first entry, drops the later one, and emits DepsDuplicatePackage warning dbt1099. The issue proposes turning that warning into a failing error; it does not say the proposed change has shipped.

Why the warning matters

A dependency change may appear in code review but never reach the installed project if another entry wins first. The package may still compile, making a release look healthy while macros or models come from an unexpected source. The dbt deps reference explains that the command installs dependencies from packages.yml; check dependencies.yml as well when your project uses it.

Audit names, not only URLs

List every package entry and the project name it resolves to. Compare local paths, registry packages, and Git packages, including forks with the same declared name. Resolve duplicates intentionally, pin the chosen revision, and review the resulting lock file or installed package contents. In CI, treat the duplicate warning as a release gate until the product behavior changes. Test that the intended macro or model is the one actually installed.

Preserve a migration trail

If a duplicate was intentional during a fork transition, document which source should win and remove the other entry in the same change. Keep a before-and-after build artifact for critical transformations so a dependency cleanup cannot silently alter business metrics.

Adovo’s view

A dependency file is a choice of code, not a shopping list. If two sources claim the same name, the team must make the choice explicitly. A warning that still builds is a governance gap until CI closes it.