I am trying to integrate an API in a yew project and facing the following issue:
Dark#Dark:/var/www/html/yew-practice$ wasm-pack build --target web
Error: Error during execution of `cargo metadata`: Updating crates.io index
Updating git repository `https://github.com/yewstack/yew`
error: no matching package found
searched package name: `yewtil`
perhaps you meant: yew
location searched: https://github.com/yewstack/yew
Cargo.toml:
[package]
name = "yew-practice"
version = "0.1.0"
edition = "2018"
[lib]
crate-type = ["cdylib"]
[dependencies]
wasm-bindgen = "^0.2"
serde="1"
yew = { git = "https://github.com/yewstack/yew" }
yewtil = { git = "https://github.com/yewstack/yew", features = ["fetch"] }
How do I solve the problem above?
The error tells you that no package yewtil was found in the Git repository. If you go to the repository and check its Cargo.toml file, you will indeed notice that it doesn't include a yewtil package.
I searched in the repository for yewtil, and found this pull request that refactored the project and merged yewtil into other packages: yewstack/yew#1842.
You have two options now:
Drop the dependency on yewtil, and use the documentation to figure out where the features have moved that you want to use.
Add a tag key to the dependency to pull in the latest release that included yewtil, or simply switch to the latest published version on crates.io.
If you want to get the latest features from yew, which appears to be the case given that you're pulling in the package from GitHub and not crates.io, go with option 1. You can use the documentation and the examples in the master branch to see how to use the package in its latest version.
Yew git repository is not a valid address, it must end with .git.
git = "https://github.com/yewstack/yew.git"
Related
I create a "workspace" with several folder within it following the tutorial I read here
It runs successfully with cargo run or cargo build
if all of the package were independent from each other, cargo package would run successfully. But as soon as one package depends on the other the cargo package will fail.
It displays: no matching package named "foo_2" found. location searched: registry "crates-io". Which is pretty weird, since I specifically add a local path on the dependencies.
Is this an intended behavior? if so, then why should I bother with workspace at all ?
The root Cargo.toml
[workspace]
members = [
"foo_1",
"foo_2",
]
foo_1/Cargo.toml
[package]
name = "foo_1"
version = "0.1.0"
edition = "2021"
# error here. It can't found the foo_2 package.
[dependencies]
foo_2 = { path = "../foo_2", version = "0.1.0" }
foo_2/Cargo.toml
[package]
name = "foo_2"
version = "0.1.0"
edition = "2021"
[dependencies]
Error message:
PS E:\Works\Experimentals\rust-workspace> cargo package --workspace
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
Packaging foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\foo_1)
Verifying foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\foo_1)
Updating crates.io index
error: failed to verify package tarball
Caused by:
no matching package named `foo_2` found
location searched: registry `crates-io`
required by package `foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\target\package\foo_1-0.1.0)`
Packaging and publishing crates requires all dependencies of said crate to also be available in a registry. For publishing this is relatively obvious, since consumers also need to be able to fetch and build transitive dependencies. Creating tarballs also happens to have the same constraints at the moment, so it is not possible if they are not meant to be published.
Whenever you have a project with many crates in a single workspace and wish to publish them on crates.io, you would start with the crate without dependencies and work your way up to the other crates.
cargo publish -p foo_2
cargo publish -p foo_1
Or, using cargo-workspaces:
cargo workspaces publish
Is this an intended behavior?
One can still publish crates in a workspace, so long as this is done in the right order. For packaging, it is a limitation at the time of writing. The current behavior could be linked with packaging being primarily part of publishing, so this could probably be improved.
If so, then why should I bother with workspace at all?
Tangential to the matter here. Workspaces exist mainly to settle other concerns, such as having a single source of compiled dependencies with a shared dependency lock. This distinction is described in that same link.
error: failed to select a version for `syn`. \
... required by package `serde_derive v1.0.125`\
... which satisfies dependency `serde_derive = "=1.0.125"` of package `serde v1.0.125`
... which satisfies dependency `serde = "^1.0.125"` of package `mongodb v2.1.0`\
... which satisfies dependency `mongodb = "^2.1"` of package `wagmeet v0.1.0
\(/mnt/e/College/Eighth Semester/Crypto_Capable/wagmeet_app)`\
versions that meet the requirements `^1.0.60` are: 1.0.86, 1.0.85, 1.0.84, 1.0.83, 1.0.82, 1.0.81, 1.0.80, 1.0.79, 1.0.78, 1.0.77, 1.0.76, 1.0.75, 1.0.74, 1.0.73, 1.0.72, 1.0.71, 1.0.70, 1.0.69, 1.0.68, 1.0.67, 1.0.66, 1.0.65, 1.0.64, 1.0.63, 1.0.62, 1.0.61, 1.0.60
all possible versions conflict with previously selected packages.
previously selected package `syn v1.0.57`\
... which satisfies dependency `syn = "=1.0.57"`
\ of package `near-sdk-core v3.0.1`
... which satisfies dependency `near-sdk-core = "=3.0.1"` of package `near-sdk-macros v3.0.1` \
... which satisfies dependency `near-sdk-macros = "=3.0.1"` \ of package `near-sdk v3.0.1`
... which satisfies dependency `near-sdk = "^3"` of package `wagmeet v0.1.0 `\
failed to select a version for `syn` which could resolve this conflict
Cargo.toml file
[package]
name = "wagmeet"
version = "0.1.0"
edition = "2021"
[lib]
crate-type = ["rlib","cdylib"]
[dependencies]
near-sdk = "^3.1.0"
near-contract-standards = "^3.1.1"
mongodb = "2.0.0"
bson = { version = "2", features = ["chrono-0_4"] } # Needed for using chrono datetime in doc
tokio = "1"
chrono = "0.4" # Used for setting DateTimes
serde = "1"
serde_derive = "1.0.135"
Update
added the cargo.toml file
I have tried various versions nothing seems to be working for now. Is mongoDb even compatible with Near protocol?
There is a conflict between two of your dependencies: near-sdk requires exactly syn version 1.0.57, and mongodb requires at least syn version 1.0.60. Clearly both cannot exist together.
You have few solutions:
Patch near-sdk to support later syn versions. This is usually not recommended.
Upgrade near-sdk to the pre-release 4.0.0 (currently 4.0.0-pre.7) that supports later syn versions. This is an unstable version, and may break.
Downgrade mongodb to a version that supports syn version 1.0.57. The latest version that supports that is 1.2.5, so you need to specify in your Cargo.toml mongodb = "=1.2.5". But this relies on an old, unsupported version.
There is no "best solution". All solutions are bad. I would probably upgrade near-sdk to 4.0.0, but what to do depends on your needs.
Try the following methods...
check your patched dependencies are pointed to the correct source repository
if you use other project's Cargo.lock or change some dependencies as you go, remove target folder and build again
check compilation logs for incorrect dependency paths!
update your Rust
delete .cargo and .rustup directories
I want to use this library: https://github.com/stepfunc/dnp3, but it is not on crates.io, it only has a repository and I can't implement it. I tried to add it to my Cargo.toml like [dependencies] dnp3 = "0.9.1" but it says that it does not exist, and indeed it does not have a crate. Inside the repository, it has some examples in dnp3/example that have use dnp3; as if it were a crate.
How can I use this?
You can directly specify a Github (or any other git repository) as the source of the dependency.
[dependencies]
dnp3 = { git = "https://github.com/stepfunc/dnp3" }
See the Cargo reference: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories
You can specify dependencies as Git repositories.
[dependencies]
dnp3 = { git = "https://github.com/stepfunc/dnp3" }
If you want to specify a branch (assuming you do not want to use main/master), you can add a branch key to the declaration above:
[dependencies]
dnp3 = { git = "https://github.com/stepfunc/dnp3", branch = "feature/rustls" }
Related read: Specifying dependencies from git repositories
Another way to do it would be to clone the repository and use a dependency with a local path.
[dependencies]
dnp3 = { path = "../dnp3" }
Related rust docs
But of course as other answers mentioned using the git version is better in your case.
I want to use an EDN parser but it is inside https://github.com/mozilla/mentat. https://github.com/mozilla/mentat/tree/master/edn has its own Cargo.toml.
I tried this:
[dependencies]
edn = { git = "https://github.com/mozilla/mentat/tree/master/edn" }
But it doesn't work.
Is it possible to add dependency to this crate inside the mentat repository?
From the Cargo documentation:
Cargo will fetch the git repository at this location then look for a Cargo.toml for the requested crate anywhere inside the git repository (not necessarily at the root).
(emphasis mine)
This means that you can just say:
[dependencies]
edn = { git = "https://github.com/mozilla/mentat" }
Following this example:
$ cargo build --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
failed to parse registry's information for: wayland-client
Caused by:
the given version requirement is invalid
This happens on every example and builds from other repos. I am running Ubuntu 16.04 LTS and I installed Cargo and Rustc through apt. Using versions: rustc 1.7.0 and cargo 0.8.0.
My Cargo.toml from the example:
[package]
name = "spinning-square"
version = "0.1.0"
authors = [
"TyOverby <ty#pre-alpha.com>",
"Nikita Pekin <contact#nikitapek.in>"
]
[[bin]]
name = "spinning-square"
[dependencies]
piston = "0.31.1"
piston2d-graphics = "0.21.1"
pistoncore-glutin_window = "0.35.0"
piston2d-opengl_graphics = "0.40.0"
I ended up using
$ sudo apt install libsdl2-dev
and then it started to work. However, I do not know if this is the true solution because I removed libsdl2 and it continued to work after that. A theory of mine is that because Piston uses sdl2, it corrected something to make it work, maybe.
If anyone has found a better solution for the next guy to have issues, I'll leave this post unanswered for a while longer.