I encountered an incredible problem

As a beginner, when I attempted to write a web server demo using Rust and the Actix framework, I consistently encountered perplexing errors. It seemed like everything was running smoothly one moment, but then, as soon as I added the 'actix-cors' dependency ('actix-cors = "0.6"') and synchronized the dependencies, I received the following error. Initially, I assumed it was an issue with my code, but even after attempting to remove the newly added code to restore normal functionality, I found that the error persisted. Regardless of how much I tinkered with the code or ran 'rustup clean,' I couldn't resolve the issue. However, prior to adding 'actix-cors,' the code was running fine. I scoured various online resources for possible solutions, but it seems that the only way to address this problem was to switch to the 'nightly' version of Rust. A great programming language should not exhibit such issues. Regardless of how this problem came about, it does not seem like a typical bug. These issues raise the learning curve, increase the overall cost of using Rust, and introduce unnecessary instability.

I believe that providing more stable and reliable tooling and dependencies is essential for the Rust ecosystem to ensure a smoother experience for all developers.

env: Mac OS 13.5, edition = "2021"
Error info:

Execution failed (exit code 101).
/Users/xxx/.cargo/bin/cargo +stable-x86_64-apple-darwin metadata --verbose --format-version 1 --all-features --filter-platform x86_64-apple-darwin
stdout : error: failed to get `std` as a dependency of package `test v0.0.0 (/Users/xxx/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/test)`

Caused by:
  failed to load source for dependency `std`

Caused by:
  Unable to update /Users/xxx/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std

Caused by:
  failed to parse manifest at `/Users/xxx/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/Cargo.toml`

Caused by:
  the cargo feature `public-dependency` requires a nightly version of Cargo, but this is the `stable` channel
  See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
  See https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency for more information about using this feature.

stderr : 

I assume you mean cargo clean, not rustup clean.

did you try remove Cargo.lock? my guess is the new crate enabled certain nightly only feature for some transitive dependencies, which then gets recorded in the lock file. but I'm not sure, I don't have enough knowledge about how cargo resolves depenencies and unifies the feature set.

I agree, but that's where we are now. the learning curve of rust is very deep, but it's mostly the consequence of the inherent complexity of the language.

rust is unique among programming languages in that it enables high level abstraction while maintains low level control, yet the language doesn't feel like being divided into different domain specific "subsets". as a result, one needs to learn a lot concepts to be able to really leverage the full power of the language.

The only effect of adding and then removing a dependency would have on the lock file is possibly updating some dependency version. If an updated version of some library becomes nightly-only, that'd be a semver error on the part of that library.

@martinwang Can you post your Cargo.toml file? That way we can take a look at your dependencies and try to reproduce the problem. You're right that this sort of thing shouldn't happen, and that means that something weird is going on. We need more info to track down the problem.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.