Advice for publishing librsvg to crates.io

[federicomenaquintero]

I want to make librsvg's Rust API available through crates.io:

• This is the main repository. In there you'll see autotools machinery for the C API, and a Cargo.toml that just defines a workspace.
• This is the librsvg crate I want to publish. It depends on...
• ... this rsvg_internals crate, which is also used by a librsvg_c_api crate in the repository, which is not of consequence here.

If I run cargo publish --dry-run while inside librsvg_crate, it tells me this:

error: no matching package named `rsvg_internals` found
location searched: registry `https://github.com/rust-lang/crates.io-index`

Fair enough, since it's being declared like this:

[dependencies]
rsvg_internals = { path = "../rsvg_internals" }

Question 1: Does this mean I need to publish rsvg_internals as well, and have it sit on crates.io as one of those crates that is available there, but one never uses directly?

Question 2: In the future I hope that the test suite, which is still implemented in C, will be ported to Rust. The test suite is much bigger than the 10 MB limit that crates.io imposes. Should I try to keep it as a separate/unpublished crate that is not used when cargo test is run in the public librsvg crate?

[bjorn3]

If you specify the version of the dependencies in addition to the path, cargo will automatically remove the path from Cargo.toml during publishing.

[kornel]

1. All dependencies have to be public and on crates-io. The top-level librsvg_crate crate doesn't seem to contain much code. I suggest merging it with internals to be a single crate. You can use privacy to hide internals, or hide them behind a feature flag with a scary name.

   • librsvg project is structured as a C project that has a Rust dependency. Consider flipping it inside-out and making it a Rust project that exports a C API. It'd be ideal if the C API was built on top of Rust public API (the crates-io crate), rather than being a sibling to the other crates.

2. Don't publish tests. They have zero value in crate tarballs, which can't run them. Use Cargo's include/exclude to remove tests from the published tarball.

[bjorn3]

@kornel

They have zero value in crate tarballs, which can't run them.

They do have value in the general case. They allow crater to check for miscompilations and libstd bugs by running the test.

[cuviper]

We also run tests if possible when packaging for Fedora, which has uncovered multiarch issues before, especially for big-endian targets.

[kornel]

Isn't crater using git repos directly?

[bjorn3]

Crater uses both crates.io as well as git repos.