dingelish / sgx-world

The world of forked crates
Apache License 2.0
23 stars 2 forks source link

No tag or branch specified in the Cargo.toml files #2

Closed liqinggd closed 4 years ago

liqinggd commented 4 years ago

Hi, We are trying to increase the rust-sgx-sdk from 1.0.6 to 1.1.0, and we have noticed that you have already moved the crates from rust-sgx-sdk/third_party here, so we modify our Cargo.toml file like this:

serde = { tag = "sgx_1.1.0", git = "https://github.com/mesalock-linux/serde-sgx", features = ["derive"] }
serde_json = { tag = "sgx_1.1.0", git = "https://github.com/mesalock-linux/serde-json-sgx" }

[patch.'https://github.com/apache/teaclave-sgx-sdk.git']
sgx_tstd = { path = "../../deps/rust-sgx-sdk/sgx_tstd" }

When compiling our project, we find that the serde_json crate in the https://github.com/mesalock-linux/serde-json-sgx also depends on the serde crate, but no tag= specified, which makes the compiling failed. image

I think the tag= should be specified in all the third_party crates to control the version of crates

Here is the cargo tree -d cmd output:

serde v1.0.104 (https://github.com/mesalock-linux/serde-sgx?tag=sgx_1.1.0#c945ac9a)
└── Occlum v0.8.0 (/root/occlum/src/libos)

serde v1.0.104 (https://github.com/mesalock-linux/serde-sgx#c945ac9a)
└── serde_json v1.0.40 (https://github.com/mesalock-linux/serde-json-sgx?tag=sgx_1.1.0#c0a62f63)
    └── Occlum v0.8.0 (/root/occlum/src/libos)

we can see there are two serde crates here.

mssun commented 4 years ago

This makes sense but I guess it needs much more efforts to maintain these crates’ versions. Especially hard when it comes to the sgx sdk which should be one and only one version among all dependencies.

So, the crates’ versions (or tags) can be strongly bind to age versions. That is, there are several sets of crates for different sgx sdk versions. When the sgx sdk version bumps, all crates need to bump corresponding dependencies’ versions and create new tags.

BTW, for the Teaclave project. We don’t use url directly. Instead, we vendored all crates and use specific versions. This will make things easier.

https://github.com/apache/incubator-teaclave/blob/develop/attestation/Cargo.toml

dingelish commented 4 years ago

The root of this problem is cargo's current implementation.

https://github.com/rust-lang/cargo/issues/7497

As you can see:

[dependencies]
a = {git = "https://github.com/aaa/bbb"}
a = {git = "https://github.com/aaa/bbb.git"}
a = {git = "https://github.com/aaa///bbb"}
a = {git = "https://github.com/aaa/bbb", rev ="0123456789abcdef"}
a = {git = "https://github.com/aaa/bbb", branch = "ccc"}
a = {git = "https://github.com/aaa/bbb", tag = "ddd"}
a = {git = "https://github.com/fff/bbb", tag = "ddd"}

All of the above 7 crates are treated as different crates.

dingelish commented 4 years ago

"Dedup by hash" in Cargo.lock is a workaround and I've successfully done this several times before. If cargo is not improved, we don't have a good way to solve it. I think we could build a tool to do this in Cargo.lock automatically.

liqinggd commented 4 years ago

Thanks for your response