What does cargo:dependency_source_missing mean?

A dependency table parsed, but it does not tell Cargo whether the crate comes from a registry version, local path, git repository, or workspace declaration.

Cargo error: dependency specified without path, git, version, or workspace

Q: How do I prevent cargo:dependency_source_missing in CI?

Test generated `Cargo.toml` files with `cargo metadata --no-deps` in the generation pipeline. Centralize repeated dependency versions and sources in `[workspace.dependencies]` when that reduces drift. Review dependency-source changes with the same care as registry and credential configuration.

Q: How can I manually validate cargo:dependency_source_missing?

Read the complete parser error and open the named `Cargo.toml`, not another workspace member with a similar dependency. Inspect the dependency entry for an empty table such as `internal-api = {}` or a template variable that rendered to an empty value. If the crate should be inherited, inspect the workspace root `[workspace.dependencies]` table and confirm the member uses `workspace = true`. For generated manifests, compare the template inputs and rendered file in the failing CI job before editing the checked-in project.

Fix it fast

Most likely: The named dependency is an empty or incomplete inline table in the manifest Cargo actually opened.

Confirm this is your error

Match the output and confirm you are troubleshooting the same failure.

error: dependency (internal-api) specified without providing a local path, Git repository, version, or workspace dependency to use
error: failed to parse manifest at `/workspace/Cargo.toml`
Caused by:
  dependency (shared) specified without providing a local path, Git repository, version, or workspace dependency to use

Check the cause

Run focused checks to identify what is failing in this environment.

cargo metadata --no-deps
grep -n "<dependency-name>" Cargo.toml
git diff -- Cargo.toml

Apply the safe fix

Use the smallest safe change that addresses the confirmed cause.

# Choose the source that matches the project.
# internal-api = { version = "1.2", registry = "company" }
# internal-api = { path = "../internal-api" }
# internal-api = { workspace = true }

Verify it works

Repeat the relevant checks and confirm the original error is gone.

cargo metadata --no-deps
cargo check

Avoid unsafe shortcuts

Keep security and data protections in place while troubleshooting.

Do not add a fake version merely to silence the parser.
Do not modify Cargo.lock because parsing failed before resolution.

What Cargo Is Rejecting

This is a local invocation problem first. Cargo stopped because the command, arguments, or working directory did not make sense before it got to the actual operation.

Fix the command

Simplify the command before you do anything else. Validate the binary version, current directory, and exact flags you are passing, then add complexity back only after the base command works.

Registry dependency:add an appropriate version = "<requirement>" and add registry = "<name>" when it is not from crates.io.

Local workspace crate:add the correct relative path, or declare it in [workspace.dependencies] and use workspace = true in the member.

Git dependency:add the canonical git URL and only the required rev, tag, or branch selector.

Generated manifest:fail the generator when required values are empty instead of emitting an incomplete dependency table.

Do not edit Cargo.lock for this error because Cargo stopped during manifest validation before lockfile resolution.

Inspect the exact manifest entry

Read the complete parser error and open the named Cargo.toml, not another workspace member with a similar dependency.

Inspect the dependency entry for an empty table such as internal-api = {} or a template variable that rendered to an empty value.

If the crate should be inherited, inspect the workspace root [workspace.dependencies] table and confirm the member uses workspace = true.

For generated manifests, compare the template inputs and rendered file in the failing CI job before editing the checked-in project.

Why the Command Was Rejected

An inline dependency table was created but no version, path, git URL, or workspace inheritance flag was added.

A manifest generator omitted a value because an environment or template variable was empty.

A workspace member intended to inherit a dependency but used an empty table instead of workspace = true.

A refactor removed the last valid source selector while retaining features, optional flags, or other dependency options.

Re-run the Minimal Correct Command

Run cargo metadata --no-deps or cargo check from the same workspace location and confirm manifest parsing succeeds, and inspect the resolved dependency source in cargo metadata before allowing a CI build to fetch from a private registry or git host.

How Cargo normalizes dependency declarations

This is the part worth understanding if the quick fix did not hold. It explains what Cargo is trying to do at the moment the error appears.

Cargo validates dependency declarations while parsing Cargo.toml, before it opens a registry index or resolves any versions.

A bare string supplies a version, while an inline table must provide a usable source selector such as version, path, git, or workspace = true.

Avoid Command and Config Drift

To prevent this, test generated Cargo.toml files with cargo metadata --no-deps in the generation pipeline, centralize repeated dependency versions and sources in [workspace.dependencies] when that reduces drift, and review dependency-source changes with the same care as registry and credential configuration.

Docs and source code

Specifying Dependencies

Official manifest syntax for registry, path, git, and workspace dependencies. - Source

Cargo supports several ways to specify the location of a dependency.

Cargo Workspaces

Official rules for inheriting dependencies from a workspace root. - Source

The workspace.dependencies table defines dependencies to be inherited by members of a workspace.