Cargo: Testing proc macro against multiple versions of a crate

help
#1

I'm writing a procedural macro that produces some typenum types, and I'd like to test an ability to override which copy of typenum its output uses (in case there are multiple versions linked).

Following the instructions in the Cargo Book to rename a dependency, my Cargo.toml looks like this:

[package]
name = "typenum-uuid"
version = "0.1.0"
authors = ["e"]
edition = "2018"

[lib]
proc_macro = true

[dependencies]
uuid = { version = "0.8", features = [ "v4" ] }

[dev-dependencies]
typenum = "=1.0.0"
tn128 = { package = "typenum", version = "^1.12.0", features = [ "i128" ] }

And produces this error:

$ cargo test
    Updating crates.io index
error: failed to select a version for `typenum`.
    ... required by package `typenum-uuid v0.1.0 (/home/e/Workbench/rust/typenum-uuid)`
versions that meet the requirements `=1.0.0` are: 1.0.0

all possible versions conflict with previously selected packages.

  previously selected package `typenum v1.12.0`
    ... which is depended on by `typenum-uuid v0.1.0 (/home/e/Workbench/rust/typenum-uuid)`

failed to select a version for `typenum` which could resolve this conflict

Is there a way to force Cargo to duplicate the dependency with multiple names like I want?

#2

You can't with crates sharing the same major version number, sadly.

  • If it is just for testing, you can work around that by having fake downstream crates that pull both your proc-macro crate and the required typenum, and then some cargo alias to run tests within both subdirs (or if you really care about cargo test Just Working, then have a native test that calls Command::new(...) to run the tests within each sub-dir).
#3

Thanks. As it's only constructing types by name, I realized that I could test the functionality by defining a private module that duplicates the typenum names. All the real functionality types can use the actual typenum crate.

1 Like