Add support for path dependencies in crates.io uploads

[GuillaumeGomez]

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.

[GuillaumeGomez]

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 ?

[alexcrichton]

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 #1169 (where it would publish both at once), so I'm going to close in favor of that. Thanks for the issue though!

[nwin]

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.

[real-or-random]

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.

[alexcrichton]

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

[crumblingstatue]

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.

[alexcrichton]

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.

[real-or-random]

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.

[alexcrichton]

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!

[gnzlbg]

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

[jakwings]

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