Would pub(workspace) be possible?

I find myself having helper crates that are only useful inside their workspace and which should not be used outside the workspace. They exist as their own crates because I want the actually-public crates to have light dependencies.

This causes two problems:

  1. I cannot easily detect unused code in these helper crates, since things are pub. There is a tool called warnalyzer that can help with this, but it's rough around the edges and might have no future since it relies on a nightly feature that has been removed.
  2. If I want to publish the actually-public crates to crates.io, I need to publish the not-really-public crates too, and afaik all I can do is add a README telling people not to use these crates directly.

I don't think there's anything that currently exists to help with this problem (would love to be wrong about this part), so I'd like to know if pub(workspace) is something that can even be added to the language, or if anyone has any other ideas

1 Like

What are light dependencies?

I don't think so. Visibility is something that exist on the language level while a workspace is a concept only applicable in the context of Cargo. Rust rightfully doesn't know anything about what build system is used to compile it, whether it is Cargo and its workspaces or some other build system like Bazel.

3 Likes

There are quite a number of projects that have "internal" crates with READMEs that advise external users not to depend on them. As noted, the workspace is a Cargo rather than rustc-level concept, but perhaps Cargo could warn against a project taking a dependency on such a package, based on suitable crate metadata.

3 Likes

Say crate A has some helper functions, and crate B in the same workspace reuses those helper functions, so B depends on A. But A is a really big crate with lots of dependencies. So if you extract the helper functions into a new small crate C, B can depend on C instead, so its dependencies are lighter.

1 Like

That sounds solvable using crate features.

crates.io doesn't publish workspaces, so pub(workspace) wouldn't help even if it was possible.

That sounds solvable using crate features.

You mean having some non-default feature that needs to be enabled in order to use the crate? I guess that could work, although as soon as you pull in one of the crates that depends on it and provides a "public" API, that will enable the feature implicitly.

That’s exactly what I meant, and that’s a good point. Maybe the other way around will work, Ie have a default feature that produces a warning, and remove default features by the owning crate