Tracking issue for RFC 1977: public & private dependencies, as it relates to the resolver

View all comments

Summary

RFC (original, superseded): #1977
RFC: #3516
Compiler tracking issue: https://github.com/rust-lang/rust/issues/44663

Implementation:

• rust-lang/cargo#6653
• rust-lang/cargo#6772
• rust-lang/cargo#6962
• rust-lang/cargo#12817
• rust-lang/cargo#13039
• rust-lang/cargo#13036
• rust-lang/cargo#13037
• rust-lang/cargo#13038
• rust-lang/cargo#13308
• rust-lang/cargo#14502
• Command to update Cargo.lock to minimal versions (rust-lang/cargo#4100)
• Make cargo publish use the minimal versions allowed by Cargo.toml
• Ensure quality of error messages is sufficient
• rust-lang/cargo#13095
• #15966

Non-blocking further improvements

• rust-lang/cargo#13096
• Proper flag to display public-private dependencies in cargo-tree (https://github.com/rust-lang/cargo/issues/6129#issuecomment-3373657472) (#16081)

Considerations for stabilization

Unresolved Issues

• How do we handle unifying public between more than one dependencies table (normal, target A normal, target B normal), both public = <bool> and default and public = true with public = false
• How to show only public dependencies in cargo tree, see also https://github.com/rust-lang/cargo/issues/6129#issuecomment-3373657472

Known Issues

• cargo add that auto-selects a version req from a transitive dep can have confusing output due to extra resolve (https://github.com/rust-lang/cargo/pull/15966#discussion_r2369220462)

Future Extensions

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Original issue

This is a sub part of the discussion of implementation of RFC 1977, specifically how the resolver could implement this protocol. The main Tracking issue is at https://github.com/rust-lang/rust/issues/44663.

This comment https://github.com/rust-lang/rfcs/pull/1977#issuecomment-304043301 described the properties we want to uphold the way that fits best with my brain.
So to use the termanology, I feel like when we are adding a packedge B we need to walk up the dependency tree to all potential C's that can see the addition to test if there is a conflicting A.
That can be done pretty fast if we have a fast way to walk up dependency tree and a fast way to see all the pub reachable packages for each ancestor. (Neither of which we have at this time.)
But that feels like a lot of state to be cloned for each tick.
Currently we avoid the expensive clones with extensive use of RC.

Is it time to add a im-rs dependency?
Is there a better algorithm?
Is there a small part that would make a good starting PR?\

This is a tracking issue rather than a self-contained change, and it names no source file, test, or entry point. Start by reading RFC #3516 and the unchecked implementation items, especially Cargo #13095, then define a focused task whose completion can be recorded in this tracking issue.