-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publishing a crate with unpublished dependencies #6738
Comments
You cannot publish a crate that relies on git dependencies. |
Right, but the error message implies that you can pull in submodules, which don't work either. |
When you have multiple crates to publish, you have to publish from the leaves first, and then work up to the root. There is a long-standing request (such as #1169) to be able to publish multiple packages at once, which would handle that automatically. |
This isn't trying to publish multiple crates; rather, it's trying publish a single crate with multiple dependencies, some of which are themselves unpublished. |
A crate cannot be published with unpublished dependencies. Can you say more about why you want to do that? It wouldn't be usable with missing dependencies. |
The dependencies aren't missing per se, but they are unpublished. Based off the error, I guess I would've thought that you can pull in dependencies that are not on crates.io via |
I'm in the same boat as @ysimonson and initially thought |
I think I understand why you can't publish a project that depends on another github repo. But why can't you publish when it sources a local directory using "path="? Doing that seems essentially equivalent to incorporating the source-code of the package into your own, which presumably would work. |
@2-complex Your cargo dependencies, path included, are different crates (i. e. different units of compilation).
That's not right, a path dependency is a different crate that gets compiled separately and then linked together. |
You also can't publish if the unpublished crate is |
Here at https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations it says
When I provide path dependency then cargo package asks for version number, and when I provide both path and version it starts looking into crate.io for the package. |
I'm only guessing: It probably only uses the path dependency if you have a version that's yet to be published on crates.io (presumably to speed up development). If bitflags has 1.0 published, then it's going to ignore your local path. (and rightfully so, I guess). |
I realize by design all deps should be published before a crate is published for now. But in my case, I make some minor patches to a dependency that won't be accepted by the upstream. I just want to keep it as-is without publishing since it is useless for general use. Could it be possible to hide some crates from appearing in the search results of crates.io? Otherwise, it might confuse others. |
I also don't see the point in publishing a patched crate, which I don't own. And, actually, I can't imagine how to manage a situation. |
Say I patch a dependency which itself has multiple workspaces. I'd have to publish each workspace I've applied patches to individually? |
I'd like to publish a crate that depends on various crates from tower-rs, which are not yet themselves published. I'm not sure how to do this.
If I specify the dependencies in
Cargo.toml
as sourced from git:I can get as far as packaging, but not publish:
If I pull in the dependencies as submodules and use paths in
Cargo.toml
:I can't package because it's trying to pull the crates from
crates.io
:If I use patch:
I get the same verification error when packaging.
Observed on stable v1.33.0.
The text was updated successfully, but these errors were encountered: