Invalid index generated: deps and features are missing

[Riateche]

alexandrie deliberately omits deps and features fields in the crate index when there are no dependencies or features. For example, this JSON is generated by alexandrie:

{"name":"tmp42","vers":"0.1.0","cksum":"7181406a66629d77cba073cc0b7e6966d46bed72d31251da1813f3166e737c5d","yanked":false}

cargo doesn't recognize such entries in the index (I set CARGO_LOG=info for internal logging):

    Updating `ssh://...` index
[2020-04-24T10:17:39Z INFO  cargo::sources::registry::index] failed to parse "tm/p4/tmp42" registry package: missing field `deps` at line 1 column 121
error: no matching package named `tmp42` found
location searched: registry `ssh://...`
required by package `tmp43 v0.1.0 (...)`

If I manually update the JSON like this, cargo recognizes it:

{"name":"tmp42","vers":"0.1.0","deps":[],"cksum":"7181406a66629d77cba073cc0b7e6966d46bed72d31251da1813f3166e737c5d","yanked":false,"features":{}}

The RFC doesn't mention anything about optional fields.

The fix would be to simply remove the skip_serializing_if attributes.

cargo --version
cargo 1.43.0 (3532cf738 2020-03-17)

[Hirevo]

Oops, I didn't expected that to happen, that change to omit some fields was quite recent, and I didn't think it would cause any issue, sorry for my oversight.
This should be fixed in #59 where, as you correctly inferred, we remove the skip_serializing_if attributes.

These kinds of issues really show the need for automated end-to-end testing for the registry.
In fact, I have started working on this and I expect to have something out very soon to address this.
After it lands (and if we do this right), these kinds of issues shouldn't appear anymore.

Sorry for the inconvenience, I hope it didn't impact you too much.
And thank you for filing this issue.