Feature discussion: Allow internal dependencies in Cargo

[mineichen]

It would be great, if dependencies in Cargo.toml could be marked as 'private', indicating, that they mustn't be used in the public interface of that library. I'd see the following benefits:

• For a library user, any version of that dependency could be used. Cargo mustn't aggree to a specific version with other dependents and could use the latest available which might already have received a patch another dependency holds back.
• Help Library users to evaluate the impact of that library in the project or one of it's dependencies. For example: If the Image crate is referenced internally only in a library, I'd use it. But it might be a showstopper if it doesn't allow me to use the latest Version of Image in my project anymore.
• As a library author, I want some dependencies to remain replaceable. Authors can avoid accidentally using a type defined in dependencies in the public api.

I'd use this marker for most crates like itertools, lazy_static, once_cell, thiserror rand, or crates which just provide proc-macros. Looking far into the future, the next rust edition should expect all dependencies to be private if not actively marked public.

What do you think about this idea?

[jhpratt]

Aren't public/private dependencies already RFC accepted, implemented, and unstable?

[CAD97]

This is already an RFC-accepted unstable feature:

https://rust-lang.github.io/rfcs/1977-public-private-dependencies.html

Tracking issue for RFC 1977: public & private dependencies

IIRC, this is primarily blocked on replacing cargo's semver solver with pubgrub and the fact that the cargo team doesn't have bandwidth for anything new (such as said migration) at the moment.

[mineichen]

@CAD97

I don't know how I could have missed that Thank you for pointing it out to me and sorry for spamming