Cargo: Add support for path dependencies in crates.io uploads

Created on 29 Apr 2015 · 12Comments · Source: rust-lang/cargo

Hi,

I have the following error when I run cargo package:

> cargo publish
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Packaging glib v0.0.1 (file:///home/imperio/rust/glib)
   Verifying glib v0.0.1 (file:///home/imperio/rust/glib)
    Updating registry `https://github.com/rust-lang/crates.io-index`
failed to verify package tarball

Caused by:
  no matching package named `glib-sys` found (required by `glib`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: ^0.1.0

The problem is that I have this sublib path in the cargo.toml file:

[dependencies.glib-sys]
path = "./glib-sys"
version = "0.1.0"

No problem with the cargo build however. So I changed the line to:

[dependencies.glib-sys]
git = "https://github.com/rust-gnome/glib"
version = "0.1.0"

(which is also the link to the library).

But when I run cargo publish:

all dependencies must come from the same source.
dependency `glib-sys` comes from https://github.com/rust-gnome/glib instead

When reading the tutorial to publish library, it says that path is supported. However it seems not. Is it a bug ?

PS: Here is the link to the glib repository.

Source

GuillaumeGomez

👍4

Most helpful comment

But #1169 is a totally different issue. This is (as far as I understand) not about uploading a sub-crate but to include sub-crates into a package.

I do not see how path dependencies should be harmful as long as they get uploaded to crates.io like any other file in the package.

nwin on 7 Jun 2015

👍7

All 12 comments

So like Dabo proposed, I think it would be nice to add path dependencies support for crates.io uploads. In the case of all rust-gnome repositories, it would be very helpful.

What do you think of it ?

GuillaumeGomez on 29 Apr 2015

Right now you'll have to publish each component of a crate independently (e.g. publish glib-sys first), and otherwise I think this falls under https://github.com/rust-lang/cargo/issues/1169 (where it would publish both at once), so I'm going to close in favor of that. Thanks for the issue though!

alexcrichton on 30 Apr 2015

But #1169 is a totally different issue. This is (as far as I understand) not about uploading a sub-crate but to include sub-crates into a package.

I do not see how path dependencies should be harmful as long as they get uploaded to crates.io like any other file in the package.

nwin on 7 Jun 2015

👍7

I agree, #1169 is different.

@alexcrichton Can you reconsider re-opening this issue? It may not be a good idea in the end but it's worth discussing.

real-or-random on 12 Jun 2017

@real-or-random what do you see the outcome of this issue being? How would this get resolved?

alexcrichton on 13 Jun 2017

The idea is to allow packages with path dependencies to be uploaded to crates.io. This could be achieved by simply packaging the path dependencies along with the main crate.

A possible motivation for this could be splitting up a project into separate crates for better compilation performance/etc., or using a private fork of some other library temporarily.

crumblingstatue on 13 Jun 2017

Such a feature is basically entirely incompatible with all of Cargo right now, and would require a significant rewrite from the ground up to support unfortunately.

alexcrichton on 13 Jun 2017

Looking at projects such as imag, which is spread over > 30 crates, I had the feeling that packaging path dependencies will be a very useful feature and that #1169 is the wrong reason to close it. I don't have any specific outcome in mind.

I'm new to rust and I'm probably the wrong person to judge the effort to build this but even some notion of a group (just on crates.io, independently of cargo) will help in certain scenarios (this will be closer to #1169 then).

On the other hand, there was a deliberate decision to use a flat namespace, and it's possible to create "meta-crates" which do nothing but depending on other crates if you want groups.

real-or-random on 14 Jun 2017

It sounds like the requested feature, in terms of cargo internals, would be to support packages that have multiple library crates. That feature is quite large and is explicitly not supported by Cargo today, but it sounds like it would solve the use case here I believe. If you'd like to open a dedicated issue for that, please feel free to do so!

alexcrichton on 14 Jun 2017

@alexcrichton we can't release stdsimd on crates.io anymore without publishing stdsimd-test :/

gnzlbg on 23 Oct 2017

@alexcrichton Hi, my idea is that sub crates with package.publish = false should be uploaded.

iology on 16 Nov 2017

This is hitting us with noria as well. Specifically, I'd like to publish the sub-crate noria-server, but it internally contains three relatively large (private) sub-crates (dataflow, mir, and common). While it would be possible to turn all those sub-crates into modules, it makes compilation painfully slow.