search

cardoe / cargo-ebuild

cargo extension that can generate ebuilds using the in-tree eclasses
Apache License 2.0
76 stars 13 forks source link

Handle local crates properly #18

Open d-e-s-o opened 5 years ago

d-e-s-o commented 5 years ago

It appears (I did not investigate) that cargo-ebuild does not handle crates that are only available locally properly. E.g., try creating an ebuild for clippy @ 486300b89dd6b06f53061a193d3477ceb3740dee. Among others, the resulting ebuild will reference rustc_tools_util and that is not available on crates.io. So ultimately manifest creation for the ebuild will fail.

>>> Downloading 'https://crates.io/api/v1/crates/rustc_tools_util/0.1.0/download'
--2018-11-03 00:00:00--  https://crates.io/api/v1/crates/rustc_tools_util/0.1.0/download
Resolving crates.io... 52.0.94.50, 52.44.144.199, 52.86.186.182, ...
Connecting to crates.io|52.0.94.50|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-11-03 00:00:00 ERROR 404: Not Found.

Should/do we handle a local path inside of Cargo.toml properly?

divoxx commented 5 years ago

I'm able to install local crates by simply remove the local crate name from the CRATES variable in the ebuild.

If the crate uses 2018 edition, then you'll likely hit this other issue: https://github.com/cardoe/cargo-ebuild/issues/24

cardoe commented 4 years ago

Please try again with cargo-ebuild 0.3.1