Skip to content
This repository has been archived by the owner on Jan 8, 2022. It is now read-only.

Handle local crates properly #18

Open
d-e-s-o opened this issue Nov 3, 2018 · 2 comments
Open

Handle local crates properly #18

d-e-s-o opened this issue Nov 3, 2018 · 2 comments

Comments

@d-e-s-o
Copy link

d-e-s-o commented Nov 3, 2018

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?
@d-e-s-o d-e-s-o mentioned this issue Dec 20, 2018
Open
@divoxx
Copy link

divoxx commented Jul 24, 2019

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: #24

@leonardohn leonardohn mentioned this issue Jun 18, 2020
Merged
@cardoe
Copy link
Owner

cardoe commented Jun 18, 2020

Please try again with cargo-ebuild 0.3.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@divoxx @cardoe @d-e-s-o