error: crates cannot be published to crates.io with dependencies sourced from other
registries. `log` needs to be published to crates.io before publishing this crate.
(crate `log` is pulled from registry `crates-io`)
error: crates cannot be published to crates.io with dependencies sourced from other
registries. `async-trait` needs to be published to crates.io before publishing this crate.
(crate `async-trait` is pulled from registry `crates-io`)
There is something strange going on here. You should not need to do anything special to publish a crate to crates.io that depends on log and async-trait from crates.io. The error message doesn't make sense, because your dependencies aren't “dependencies sourced from other registries”.
I don't have an idea for how to troubleshoot this, but it's not just a mistake in your code. Maybe something is long with your local Cargo registry information in ~/.cargo/, somehow?
When I build, I success, and there is an error in publish
cargo package --allow-dirty
success
âžś mybatis-drive git:(v-1.0.1) âś— cargo publish --allow-dirty
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package: /Users/jameszow/Documents/RustWorkSpace/summer-mybatis/mybatis-core/Cargo.toml
workspace: /Users/jameszow/Documents/RustWorkSpace/summer-mybatis/Cargo.toml
Updating `ustc` index
error: crates cannot be published to crates.io with dependencies sourced from other
registries. `base64` needs to be published to crates.io before publishing this crate.
(crate `base64` is pulled from registry `crates-io`)
I've read it, but I still don't have a clear solution. In our country, if you don't replace the source, cargo download is very slow, Thank you very much for helping me find the problem
If the problem is “only” crates.io being slow, you could maybe temporarily disable the config only while executing cargo publish? Although, during publishing, I guess cargo might possibly want to re-download all the crates from the new source then, so the cargo publish invocation might be slow, too? I don’t know whether or not that would be the case. And I don’t know either if the slowness is only a slight inconvenience or if it’s so significantly slow that it takes ages to complete (which might also depend on the number of dependencies, I guess..)
It is very slow, just like Java Maven's warehouse. In our country, it is pulled with replacement sources. This has a certain relationship with network speed and bandwidth. I think we can track this problem, because it has not been reasonably solved for 2 years, and its error prompt is very misleading to developers