cargo package doesn't work with child packages

[lifthrasiir]

$ cargo package --verbose
   Packaging encoding v0.2.0 (file:///path/to/rust-encoding)
   Archiving .gitignore
[snip]
   Archiving src/util.rs
   Verifying encoding v0.2.0 (file:///path/to/rust-encoding)
    Updating registry `https://github.com/rust-lang/crates.io-index`
failed to verify package tarball

Caused by:
  no package named `encoding-index-japanese` found (required by `encoding`)
location searched: the package registry
version required: ^1.0.20140915

Cargo package only archives files for the current package, the strategy which do not work for packages with child packages like rust-encoding (index tables) or gl-rs (generators). This is primarily a problem of PathSource::list_files_* excluding child packages, but also a problem of the basic design---"should one archive represent only one package?".

[SimonSapin]

Adding to this: The current design seems to be that each crate should be published separately. This design seems flawed, since crates are also the compilation unit. There are plenty of reason to split a single "project" into multiple compilation units: reducing build times, using a compiler plugin, … But the "project" as a whole is still the thing I want to publish and give a version number to, using the internal crates individually doesn’t necessarily make sense.

Please consider adding a new concept of "project" or "package" (or whatever it should be called): the thing that is published on crates.io, and consists of a "root" crate and zero or more additional crates that are path dependencies.

[alexcrichton]

It's true that this is by design and currently intentional, but @SimonSapin those are indeed some interesting points. For the near term we're gonna have to live with publishing each crate separately, but we can certainly investigate implementing something like this.

cc @wycats, I'm curious what you think here as well?

[alexcrichton]

Ooops...

[IvanUkhov]

I wonder how ssh2-rs works then. It has a child package called libssh2-sys, and, since it’s published, cargo package shouldn’t have any problems with it. I’m asking because I’m experiencing a similar problem where cargo package doesn’t seem to be archiving my local dependencies. Thank you.

Regards,
Ivan

[alexcrichton]

@IvanUkhov you'll have to publish each dependency independently (via cd ... && cargo publish e.g.)

[alexcrichton]

I'm closing this as it's working as intended, but I've opened #1169 to make this more ergonomic.