Advice for publishing librsvg to crates.io

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

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?

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

1 Like
  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.

2 Likes

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

1 Like

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

Isn't crater using git repos directly?

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

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.