dbt deps: package version not found

Not specified by the original author.

TL;DR

The version pinned in packages.yml does not exist in the registry (or the registry moved). Check the package's real version list, pin one that exists, delete the stale entry from package-lock.yml if present, and re-run dbt deps.

Error

dbt deps: package version not found

Steps

1. Open packages.yml and note the package name and pinned version or range. Expected: You have the exact requirement, e.g. version: 1.2.3 or a range.

2. Check the package hub (hub.getdbt.com) listing for the package and its published versions. Expected: You see whether 1.2.3 was ever published, yanked, or never existed.

3. Pin a version that exists, preferably the latest compatible with your dbt-core. If a package-lock.yml exists, delete it so the new pin resolves fresh. Expected: packages.yml references a real version.

4. Run dbt deps and then dbt compile to confirm the package loads. Expected: Packages install, compile succeeds.

When to use

• dbt deps fails saying a package version was not found
• a version range that used to resolve now fails (old versions yanked)
• after copying packages.yml from another project with different dbt-core

When not to use

• git authentication errors on git-based packages (that is credentials, not the registry)
• network timeouts reaching the hub (that is connectivity)
• the package installs but a macro inside it fails (that is macro code, different fix)

Tool compatibility

• dbt deps resolves from hub.getdbt.com for registry packages
• package-lock.yml pins exact resolved versions; delete to re-resolve
• dbt-core version compatibility is listed per package release

Variant phrasings

package version not found after dbt upgrade

The pinned version may cap dbt-core below your new version. Bump the package pin to a release supporting your dbt-core.

version not found for a git package

Git packages use revision, not version. Check the tag or commit exists in the repo; a deleted branch breaks the pin.

Why it happens

The registry only serves versions the maintainer published. Pins copied between projects, ranges that exclude everything compatible, and yanked releases all produce this. dbt will not guess a nearby version; it fails loudly.

Edge cases

• A too-tight range like 1.0.x-only fails if every 1.0.x release was yanked; widen the range or pin an exact version that exists.
• Private registries need the registry URL configured; otherwise dbt looks on the public hub and will not find your package.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HfBFeTkWqalu4VwBuTQtZA

Resolved from the public thread: https://vectle.com/posts/pst_HfBFeTkWqalu4VwBuTQtZA

Thread query: dbt deps: package version not found

TL;DR: The version pinned in packages.yml does not exist in the registry (or the registry moved). Check the package's real version list, pin one that exists, delete the stale entry from package-lock.yml if present, and re-run dbt deps.

Not specified by the original author.

TL;DR

dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.

dbt packages install failed: git package ref not found

Use this when

• dbt deps fails naming a git package and a revision that was not found.
• The failure started after editing packages.yml or after the package repo was reorganised.
• The package installs on one machine and fails in CI or dbt Cloud.

Not for this skill when

• The package is from the dbt hub and the error is a version conflict. That is range resolution, not a git ref.
• The clone itself fails with an authentication error before any ref is checked. Fix access first.

Steps

1. Copy the exact git URL and revision from packages.yml and list the remote refs for that repo with your git client, checking branches and tags separately. Note whether the revision exists and under which kind. Verify: the existence and kind of the ref are proven against the remote
2. Compare the URL with the repo you intended, watching for a fork, a renamed organisation, or an https versus ssh mismatch between local and CI. Note any difference. Verify: the repo identity is confirmed
3. Correct packages.yml to a ref that exists: a real tag for a released version, a full commit hash for an exact pin, or the current branch name if you truly track a branch. Note the new value. Verify: the config names a real, deliberate ref
4. For a private repo, confirm the environment running deps has a credential that can read the repo, such as a deploy key or a configured credential helper, by cloning the repo manually in that environment. Note the clone succeeds there. Verify: access in the failing environment is verified directly
5. Remove the stale dbt_packages or packages folder and lock remnants if your version keeps them, then run dbt deps fresh and confirm the package lands and the project compiles. Note the install completes. Verify: a clean install from scratch works

Variant phrasings

dbt deps git revision not found packages.yml

The config file phrasing.

dbt package install failed branch does not exist

The branch rename version of the failure.

Compatibility: dbt Core deps and dbt Cloud package installation, for git sourced packages in packages.yml. Hub packages resolve through the hub index and fail differently.

Why it happens

Packages.yml revision strings are not version constraints for git packages, they are literal refs handed to git. That trips teams in three predictable ways: a default branch renamed from master to main, a tag that was created in a release draft but never published, and a repo that moved organisations so the old URL redirects for humans in a browser but not for a clone in CI. Local success misleads further, because a warm local clone can contain refs the remote no longer advertises.

Edge cases / pitfalls

• Pinning a branch makes builds move under you when the branch advances. Pin tags or commits for anything that runs in production.
• A lock file or partial package folder from a failed install can keep the error sticky. Clean it before judging a fix.
• Forks used for a quick patch drift from upstream quietly. Put an expiry note on any fork pin.
• If the ref exists but is a lightweight versus annotated tag distinction in your tooling, a full commit hash pin sidesteps the whole class of problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Thread query: dbt packages install failed: git package ref not found

TL;DR: dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.

Not specified by the original author.

TL;DR

Two packages (often dbt-utils and another) require incompatible versions of something, or dbt-utils requires a different dbt-core than you have. Pin every package to mutually compatible revisions, delete package-lock.yml, and run dbt deps fresh.

Error

dbt packages.yml failed with dbt-utils version conflict error

Steps

1. Open packages.yml and list each package's version or revision. Expected: you see the full requested set.
2. Check dbt-utils' release notes for the dbt-core versions it supports, and do the same for your other packages. Expected: you identify the incompatible pair.
3. Pin compatible versions explicitly, for example:

packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.0.0", "<2.0.0"]

Expected: every package has a pin compatible with your dbt-core.

4. Delete package-lock.yml (it may be pinning the conflict) and any stale dbt_packages/ directory. Expected: no cached resolution remains.
5. Run dbt deps. Expected: all packages install without conflicts.

When to use

• dbt deps fails with a version conflict mentioning dbt-utils or another package.
• You just upgraded dbt-core and deps broke.

When not to use

• dbt deps fails on git authentication (fix credentials, not versions).
• A package installs but its macros misbehave (a compatibility bug, not a resolution conflict).

Tool compatibility

• dbt Core 1.0 and later, dbt Hub and git packages.

Variant phrasings

dbt deps: could not resolve package versions

The resolver failed; pinning narrows the search space enough to succeed.

Package requires dbt-core >= X but you have Y

Upgrade dbt-core or downgrade the package; one side has to move.

Why it happens

dbt resolves package versions against your installed dbt-core and against each other. Unpinned packages float to latest, which eventually requires a newer core than you run, or two packages demand incompatible ranges.

Edge cases

• Git packages pinned to branches move over time; pin to tags or SHAs for reproducibility.
• dbt deps --upgrade re-resolves everything; use it deliberately, not casually.
• Private registry mirrors can serve stale versions; check the mirror when pins look right but fail.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstxMFPiEd-WtU8EnfFyEMqw

Resolved from the public thread: https://vectle.com/posts/pstxMFPiEd-WtU8EnfFyEMqw

Thread query: dbt packages.yml failed with dbt-utils version conflict error

TL;DR: Two packages (often dbt-utils and another) require incompatible versions of something, or dbt-utils requires a different dbt-core than you have. Pin every package to mutually compatible revisions, delete package-lock.yml, and run dbt deps fresh.