`paths` config override does not override `path` of nested dependencies

[lucab]

According to the cargo guide, paths parameter in a config file should be used to add local overrides for dependencies. However, I found this not to be working for many crates, due to nested dependencies declaring an explicit path. Nested dependencies are NOT being picked up from my local paths.
The scenario to reproduce is as follow.

I have a test project that needs env_logger. The Cargo.toml is as follow:

[project]
name = "test"
version = "0.1.0"
authors = [ "me <me@example.com>" ]

[dependencies]
env_logger = "0.3"

[[bin]]
name = "test"

I have a local copy of all the crates I need under /srv/deps/, so:

• env_logger under /srv/deps/env_logger-0.3.1
• log under /srv/deps/log-0.3.1/ (needed by env_logger)

I have a local override under .cargo/config which looks like this:

paths = [
"/srv/deps/log-0.3.1",
"/srv/deps/env_logger-0.3.1"
]

However, trying to build with cargo fails with:

Unable to update file:///srv/deps/env_logger-0.3.1

Caused by:
  Could not find `Cargo.toml` in `/srv/deps`

This is because env_logger currently has a dependency on log specified as follow:

[dependencies.log]
version = "0.3"
path = ".."

I believe this is a bug, as it is my understanding that local config overrides should take precedence over library manifests.

[alexcrichton]

This sounds like you're taking the source directly from crates.io and then using it as a path dependency? That's unfortunately not going to work for this reason (Cargo rewrites path dependencies to be crates.io dependencies).

Otherwise this is working as intended because the path override for env_logger says it depend on a crate which doesn't exist, so I'm going to close this as working as intended.

[lucab]

This sounds like you're taking the source directly from crates.io and then using it as a path dependency? That's unfortunately not going to work for this reason

Yes I am. I'm taking released artifacts and making them locally available for offline/reproducible/signed builds. Maybe I took the wrong approach also given the lack of answers here, but this should be a fairly normal scenario for a package builder/manager.

(Cargo rewrites path dependencies to be crates.io dependencies)

If I understand correctly, this means that "entries for dependencies fetched to disk are synthesized to Cargo.lock in the parent project and then they override the original path."

Otherwise this is working as intended because the path override for env_logger says it depend on a crate which doesn't exist, so I'm going to close this as working as intended.

Are you suggesting that all those packages are declaring buggy dependency paths? They don't make much sense when speaking about released artifacts/packages, but only in a git repo context. But it is my understanding that dependencies are declared in term of packages. Can you please clarify, as I fear I have some misunderstanding on the intended design?

[lucab]

But it is my understanding that dependencies are declared in term of packages.

I've been corrected by @steveklabnik, this was my root misunderstanding. Dependencies are declared in terms of crates, not packages. Thanks both for the answers.

[alexcrichton]

Ah and to also clarify, Cargo doesn't modify Cargo.toml when it uploads a crate to crates.io. Hence the Cargo.toml in the env_logger crate is indeed valid (it's path dependency on log points to an actual package) within the context of the repo it came from, it's just that from the context of the crates.io download that it's invalid.

If you're downloading crates to have them available locally, you'll probably want to rewrite all Cargo.toml entries to point use path dependencies (instead of overrides) and that'll auto-apply for transitive dependencies through crates.io that originally came from paths