Allow omission of version for dev- and build- dependencies that are also regular dependencies

tools and infrastructure
1

Let's say we're writing a library. And there is a crate that is both a regular dependency and a dev dependency for our crate. We would like to select the version once for both uses.

[dependencies]
dd_maths_traits = { version = "0.1.6" }
# ....

[dev-dependencies]
dd_maths_traits = { features = ["std"] }

However, currently

Note : When a package is published, only dev-dependencies that specify a version will be included in the published crate. For most use cases, dev-dependencies are not needed when published, though some users (like OS packagers) may want to run tests within a crate, so providing a version if possible can still be beneficial.

and Cargo will emit the following

warning: dependency (dd_maths_traits) specified without providing a local path, Git repository, or version to use. This will be considered an error in future versions

In my opinion, it would be reasonable to omission of version for dev- and build- dependencies that are also regular dependencies.

1 Like
2

A short term option is for cargo add to prefer existing similarly-renamed versions of a crate for version selection.

Longer term, I think RFC 2906 covers this, despite it being focused on workspaces (you could just have a workspace of one).

1 Like
3

Support for copying existing version requirements from other tables is now in cargo-edit master. See PR 616 for details.

2 Likes
4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.