Star "*" notation in Cargo.toml is not picking the correct dependency version

[MaksymZavershynskyi]

I just tried to compile the contract with the following Cargo.toml:

[package]
name = "fungible-token"
version = "0.1.0"
authors = ["Near Inc <hello@nearprotocol.com>"]
edition = "2018"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
serde = { version = "*", features = ["derive"] }
serde_json = "*"
near-sdk = "0.9.2"
borsh = "*"
wee_alloc = { version = "0.4.5", default-features = false, features = [] }

And received the following error:

warning: build failed, waiting for other jobs to finish...
error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>: borsh::ser::BorshSerialize` is not satisfied
  --> fungible-token/src/lib.rs:23:28
   |
23 | #[derive(BorshDeserialize, BorshSerialize)]
   |                            ^^^^^^^^^^^^^^ the trait `borsh::ser::BorshSerialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:10
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |          ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>: borsh::de::BorshDeserialize` is not satisfied
  --> fungible-token/src/lib.rs:23:10
   |
23 | #[derive(BorshDeserialize, BorshSerialize)]
   |          ^^^^^^^^^^^^^^^^ the trait `borsh::de::BorshDeserialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, u128>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:26
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |                          ^^^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>: borsh::ser::BorshSerialize` is not satisfied
  --> fungible-token/src/lib.rs:58:28
   |
58 | #[derive(BorshDeserialize, BorshSerialize)]
   |                            ^^^^^^^^^^^^^^ the trait `borsh::ser::BorshSerialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:10
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |          ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>: borsh::de::BorshDeserialize` is not satisfied
  --> fungible-token/src/lib.rs:58:10
   |
58 | #[derive(BorshDeserialize, BorshSerialize)]
   |          ^^^^^^^^^^^^^^^^ the trait `borsh::de::BorshDeserialize` is not implemented for `near_sdk::collections::map::Map<std::vec::Vec<u8>, Account>`
   |
help: trait impl with same name found
  --> /Users/maksymzavershynskyi/.cargo/registry/src/github.com-1ecc6299db9ec823/near-sdk-0.9.2/src/collections/map.rs:14:26
   |
14 | #[derive(BorshSerialize, BorshDeserialize)]
   |                          ^^^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `borsh` are being used?
   = help: see issue #48214
   = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `fungible-token`.

To learn more, run the command again with --verbose.

Notice that it complains about borsh version being incompatible with whatever version we use in near-sdk-rs. It seems like "" notation does not pick the correct compatible version. After I replaced `borsh = "" withborsh = "0.6.1"` it compiled successfully.

---

• We need to remove "*" from all our examples and stop advising people to use "*" notation. CC @mikedotexe
• We should finish https://github.com/near/near-sdk-rs/issues/142 and re-export at least borsh. CC @frol

CC @evgenykuzyakov

[MaksymZavershynskyi]

Note, reproducibility of this issue might be difficult, since it might depend on the local cargo cache.

[chadoh]

@nearmax I got this same when upgrading dependencies in pow-faucet. @evgenykuzyakov advised me to delete Cargo.lock and rebuild, and that worked

Would it work here as well?

[frol]

Re-export is mostly done. AFAIK, all the issues are resolved, but @evgenykuzyakov is busy finishing the contracts, so he said he would have the bandwidth only the next week (it sounded fine to me). “*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

[chadoh]

@frol @nearmax @evgenykuzyakov I'm still not clear on if we actually want this.

“*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

Does this mean we should stop using it? Or is it a normal Rust workflow to delete Cargo.lock when these sorts of issues are encountered?

[MaksymZavershynskyi]

@frol @nearmax @evgenykuzyakov I'm still not clear on if we actually want this.

“*” versioning is very conservative and it will indeed try to keep Cargo.lock with minimal changes if possible causing such mismatches.

Does this mean we should stop using it? Or is it a normal Rust workflow to delete Cargo.lock when these sorts of issues are encountered?

We have recurrent complains from people copying one of our examples and getting obscure compilation errors as you have observed. This is because of "*" notation. "*" notation is not meant to "fix" the dependencies mismatch, and the reason why it was introduced is because we thought it was. So now that we have observed that it does not fix anything and causes obscure compilation errors we need to finish re-export, and finally fix this issue.

[chadoh]

we need to finish re-export, and finally fix this issue

Sorry, still not quite understanding, but I think that's because I'm thinking about this from the perspective of other apps, such as any created with create-near-app

Will the "re-exporting" change you're making here in near-sdk-rs allow other apps to use the * syntax without issue?

[MaksymZavershynskyi]

Will the "re-exporting" change you're making here in near-sdk-rs allow other apps to use the * syntax without issue?

It will make "*" unnecessary.

[chadoh]

Even better! Thanks for the clarification.

[evgenykuzyakov]

obsolete.