When cargo pulls a dependent library crate from git, it attempts to reference the dependent library's dev-dependencies.

[johnpbatty]

Description

When Cargo pulls a dependent library crate from git, it attempts to reference the dependent library's dev-dependencies. If these are not present, it complains that it cannot find their Cargo.toml.

If Cargo.toml references the same dependent library by path then the operation works as expected (dev-dependencies are ignored).

The cargo docs say:

Dev-dependencies are not used when compiling a package for building, but are used for compiling tests, examples, and benchmarks.

These dependencies are not propagated to other packages which depend on this package.

Both of these comments imply that cargo should not be attempting to reference dev-dependencies when building a lib crate into another package.

Repro

$ cargo --version
cargo 0.23.0 (61fa02415 2017-11-22)

I’ve got a test lib:

[package]
name = "my-awesome-lib"
version = "0.1.0"
authors = ["Bob"]

[dependencies]

[dev-dependencies]
devtools = { path = "devtools" }

The devtools directory does not exist in code management (the git repo) - it is auto-generated by external tools when developing locally.

I’ve also got a test bin that uses this lib:

[package]
name = "my-awesome-bin"
version = "0.1.0"
authors = ["Bob"]

[dependencies]
my-awesome-lib = { path = "../my-awesome-lib" }
#my-awesome-lib = { git = "ssh://git.datcon.co.uk/jpb/my-awesome-lib" }

If I refer to the lib via a local path it compiles (i.e. ignores the dev-dependencies), which is the expected behaviour.

If I comment out the path version and replace with the git version then it fails, as it appears the git repo-fetching code looks in the empty devtools directory for Cargo.toml, and fails when it can't find it.

[my-awesome-bin]$ cargo build
    Updating git repository `ssh://git.datcon.co.uk/jpb/my-awesome-lib`
error: failed to load source for a dependency on `my-awesome-lib`

Caused by:
  Unable to update ssh://git.datcon.co.uk/jpb/my-awesome-lib

Caused by:
  Could not find `Cargo.toml` in `/opt/rust/.cargo/git/checkouts/my-awesome-lib-5f274f0894d0da55/52259d9/devtools`

[alexcrichton]

Thanks for the report! What version of Cargo are you using? I would have expected this to be caught by this logic...

[johnpbatty]

$ cargo --version
cargo 0.23.0 (61fa02415 2017-11-22)

[johnpbatty]

From the error message it looks to me like it is bailing out due to find_project_manifest_exact(...) just before the section you highlighted.

[johnpbatty]

I guess you need to decide whether you should accept a missing Cargo.toml for the same reasons that you give for accepting a malformed Cargo.toml, and if so then treat them in the same way.

[johnpbatty]

...but then again, that feels like a bit of a hack. The fundamental issue is that it is reading dev dependencies when it should be ignoring them. Makes me wonder whether read_manifest(...) should be passed info about which dependency sections it should extract/return?

[alexcrichton]

Ah indeed! I think we'd probably just apply the same fix here, in this case the "malformed manifest" is mostly just a different one I think

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!