Multiple deps with same name but no version does not work

[apoelstra]

Consider the following fuzz/Cargo.toml:

# ...
[dependencies]
miniscript = { path = "..", features = [ "compiler" ] }
old_miniscript = { package = "miniscript", version = "12.3" }
# ...

where the initial miniscript has version 13.0. The issue with having mulitple dependencies with the same name was reported in #83 and fixed (at great complexity) in d6f28aa. However, if we look at the code in that commit:

d6f28aa#diff-facb01e83a0e857f2b36f8d94bfb4241c6af2c0cad2716fa7f25c7cb0e89882bR588-R597

We see that, when we encounter the package name miniscript, we iterate through all packages we know by that name, and look for one that matches package_dep.req. In the second line of my Cargo.toml, package_dep.req describes the version = "12.3" requirement and the correct package will be found. But in the first line, package_dep.req is empty (you can check by adding debug printlns) so any package will match and it's more-or-less random whether you'll get the right one.

If it chooses the wrong one, then it will set the package ID for both deps to miniscript 12.3.0, and then buildRustCrate will only see one of them, and you will get compilation errors about one of old_miniscript or miniscript being missing.

The way cargo itself resolves this, I think, involves some special-casing of path where it reads the Cargo.toml at the given path and infers a version from there. I debug-printed all the variables that seemed potentially useful at this point in the code and none of them had enough information to do the right thing. So I'm really not sure what the right course of action for a fix here is.

[apoelstra]

I also explored indexing packages by something other than name, but (as you undoubtedly noticed when fixing #83) this doesn't seem workable, because prior to resolving the dependencies, the name is pretty-much all you know.

It's easy enough for the user to work around this by adding a version field to all lines in the Cargo.toml.