How to publish a crate that needs fixes to dependencies



I’m trying to publish my first crate (!!) and encountered the following error:

error: crates cannot be published to with dependencies sourced from a repository
either publish `cpuprofiler` as its own crate on and specify a version as a dependency or pull it into this repository and specify it with a path and version
(crate `cpuprofiler` has repository path ``)

I understand that this is because I’m specifying the dependency as something that doesn’t live within and wants to ensure that the build is self-contained within that domain (right?). I’m wondering what the alternative is.

One option I can think of is just vendoring the crate in my own repository and point at it with path from the Cargo.toml specification. But… that seems ugly: the code already lives elsewhere and can be referenced with a unique identifier, so it’d be nice to use that copy…

But do I have alternatives? From the Specifying dependencies documentation, I thought [patch.crates-io] would work, but it doesn’t either.


1 Like

If you can’t get cpuprofiler to take and publish your fix, your main alternative is to fork and publish your own version of that crate. Since it’s small, you could also consider just embedding cpuprofiler as a module in your own crate until the fix is resolved.


I don’t like the idea of publishing forks of those crates… the crate I’m working on is a tool, not a library, so properly representing these dependencies is not that important. (The only reason I want to upload my code to is to let cargo install work.)

I’d prefer to keep a copy of these modified dependencies in my own tree until the PRs are accepted / a new version is released. I’m trying to get this to work by using a git submodule to pull in the remote code verbatim… but can’t figure out how to make Cargo happy about it. Well, I mean, I have been able to make things build, but either cargo package doesn’t see the local changes, or cargo publish is still unhappy.



Right, Cargo still won’t let you publish it as a nested crate. You’ll have to make it a module to bundle it this way. That means merging the build script with your own (if any), and positioning the source as a mod cpuprofiler instead of a crate.

1 Like

Now I’m getting quite confused though. When I look at two of the crates I use in my project, both seem to have git and path dependencies in their Cargo.toml files – yet both exist in and work as I expect. See nix’s Cargo.toml dependency on libc and fuse’s Cargo.toml dependency on fuse-sys. How are they doing this?


The versions published on don’t use Git dependencies - they’ve switched to using them since their last public release. They’ve most likely done this to unblock development while waiting on the next release of that dependency. If that hasn’t happened by the time they come to do a release, they’ll either have to wait or use one of the strategies that @cuviper mentioned :slight_smile:

1 Like

Oh I see. In the nix case, its Git history shows that they fix dependencies to specific versions right before release. And in the fuse case, the fuse / fuse-sys split only happened after the last published release (and is why fuse-sys is just a placeholder for now). Meh.

I’m still curious about one thing though: the original error I posted says or pull it into this repository and specify it with a path and version. What does this exactly mean? I thought this was saying to put path = ... in the dependency specification… but that’s not true. And I can’t read this as cuviper’s suggestion of putting the code in my tree and referencing it just like an extra module with mod foo


I believe this is referring to the last bit of this section from the docs - you can have multiple crates in one repository and link them together via path dependencies, but when you come to publish a crate, all of those crates must be published, and you must also specify a version for each one. I think this is to allow you to use a local version during development while still having a published version for other people to use?


Oh look, that section you reference does actually make this clear:

However, crates that use dependencies specified with only a path are not permitted on If we wanted to publish our hello_world crate, we would need to publish a version of hello_utils to and specify its version in the dependencies line as well:

and I had skipped over it… sorry!

Now… to wonder if it’s really worth for me bothering with creating the crate at this point. Forking the two crates I need (cpuprofiler and fuse) inside my own tree is rather ugly. If only I could get the upstream authors to respond…