Yes, crates that depend on your library will ignore your Cargo.lock. The Cargo FAQ provides more details: Why do binaries have Cargo.lock in version control, but not libraries? The purpose of a Cargo.lock is to describe the state of the world at the time of a successful build. It is then used to provide deterministic … Read more
Crates uploaded to crates.io (and thus to docs.rs) will show what feature flags exist. crates.io issue #465 suggests placing the feature list on the crate’s page as well. Beyond that, the only guaranteed way to see what features are available is to look at the Cargo.toml for the crate. This generally means that you need … Read more
To add to the given answers, a library compiled as a cdylib (docs) can generate this error when you try to reference it in another project. I solved it by separating the code I wished to reuse in a regular lib project.
Install and run cargo-cache to clear the cache in the ~/.cargo folder: cargo install cargo-cache cargo cache -a
cargo install is used to install binary packages that happen to be distributed through crates.io. If you want to use a crate as a dependency, add it to your Cargo.toml. Read the Rust getting started guide and the Cargo getting started guide for further information. In short: cargo new my_project cd my_project echo ‘curl = … Read more
In order for an item to be exported from a library crate, there must be at least one path leading to it in which every component is public. This means that all you need to make an item public within your crate but not exported from the crate (I’ll call this “internal” from now on, … Read more
Add a dependency section to your executable’s Cargo.toml and specify the path: [dependencies.my_lib] path = “../my_lib” or the equivalent alternate TOML: [dependencies] my_lib = { path = “../my_lib” } Check out the Cargo docs for specifying dependencies for more detail, like how to use a git repository instead of a local path.