Attempting to vendor a crate with virtual manifest (diesel) leads to user confusion and compilation errors

[kespindler]

Problem

While I encountered this issue while attempting to vendor diesel, this seems to be a problem related to cargo rather than diesel, so I'm filing it here.

This bug is best showcased through a repo, as it relates to several different attempts at including dependent packages in a binary crate:

https://github.com/kespindler/cargo-virtual-package

In the first commit in that repo, I can cargo build successfully, using a reference to diesel = "1.4.3" in Cargo.toml.

In the second commit, cargo build also succeeds, this time sourcing the diesel package from git(hub).

In the third commit, cargo build fails, because replacing diesel = { git = "..." } with diesel = { path = "..." } causes cargo to get confused because diesel has a virtual manifest.

Lastly, the 4th commit cargo build fails again, because while the virtual manifest issue is fixed, cargo encounters compilation issues on the diesel crates. I think this is some issue related to choosing the wrong edition or compiler version for the crate, but I'm not sure.

EDIT: diesel has a rust-toolchain file which seems to be the cause of the errors. It seems that it is ignored when including the submodules of the virtual manifest.

Possible Solution(s)
Fundamentally, I'd expect that <crate> = { git = "..." } and <crate> = { path = "..." } in a Cargo.toml would behave the same way.

Notes

I encountered this with cargo/rustc 1.40, but a quick check shows this to be the case in 1.41 as well.

[ehuss]

I don't know if there is much Cargo can do here due to the way diesel is configured. It makes use of replace which will only work within the diesel workspace. There are a few options:

• Diesel can use dual-source dependencies instead of replace. That is, it would specify both the version and the path for local dependencies. This would make it use the local path when built locally, and the specified version when published.
• You can replicate the replace tables in your workspace. Note that replace is deprecated, and patch should be used, so I would recommend that instead.
• Start with the diesel dependency pointing at crates.io, and use cargo vendor which will download the copies locally, tying everything together correctly.

Setting up a patch table is probably the easiest option.

There is a vague idea of adding nested workspaces to Cargo (#5042), but I don't think it has gotten very far.

[ehuss]

I'm going to close this, as it is somewhat expected behavior (albeit unfortunate). There are other issues tracking enhancements to workspaces (such as nested workspaces).