'version_req' keyname should be 'req'

[ian-p-cooke]

when meuse creates the crate description it writes a key 'version_req'. that should be just 'req' as specified in https://github.com/rust-lang/rfcs/blob/master/text/2141-alternative-registries.md. cargo won't download the crate as published but after editing the repo and doing a search/replace I was able to download the crate.

[mcorbin]

I think this is a cargo issue.

The crates metadata are generated by Cargo. The key is indeed req in the alternative-registries rfc and in the cargo documentation (https://doc.rust-lang.org/cargo/reference/registries.html), but is version_req in the cargo nightly documentation: https://doc.rust-lang.org/nightly/cargo/reference/registries.html.

I'm able to fetch a crate from Meuse if the crate does not have dependencies. If a crate has a dependency, I should indeed replace version_req by req in the crate metadata to be able to fetch it.

I could transform version_req to req in Meuse, but I would like to know why Cargo is pushing the crate with version_req instead of req.

[ian-p-cooke]

I looked at this a little more and I think what cargo publishes isn't intended to go directly to the git index. notice there's a format for an index entry that uses 'req' and another format for the body of a publish request that uses 'version_req'. You can see crates.io building a git dependency from the published data here: https://github.com/rust-lang/crates.io/blob/e2f20c70093a91169e8a654e2a87a035ae3a54a7/src/models/dependency.rs#L115 and it's setting 'req' of the dependency to 'version_req' of the published crate.

so... I think my title is wrong here... it's not just just the keyname that's different, it's the whole serialized object. But they're so similar that it happens to work with just renaming that key. very odd/lucky!

[mcorbin]

You are right. The format in the git repository should now be OK ;)

[ian-p-cooke]

confirmed a fresh publish can be downloaded by another project using the private registry.