Cargo pre-planning: Manifest changes

[nrc]

• pub/priv deps
• specifying tools versions, toolchain versions (rustc versions?)
• per-target deps
• more fine-grained feature flags

cc @dwijnand, @joshtriplett

[Eh2406]

cc @Eh2406 as well.

[ehuss]

I'm particularly interested in improving feature flags. There are multiple enhancements that I think should be looked as a whole to ensure they all fit together (I'm not proposing they all should be done). The general categories that I see are:

• Splitting dependency kinds. This is regarding shared dependencies (such as build-dependencies and regular dependencies) avoiding feature unification. One of the biggest use cases is to avoid no-std crates from getting std turned on due to build/dev dependencies, but there are various others.
• Graph-wide feature selection ("automatic features"). Right now, every crate needs to carefully bubble their dependencies' features up if you want to be able to control them. Improving this would make it easier to opportunistically enable things only if it is available.
• Workspaces and features. The -Z package-features flag. In general features in a workspace seem like a mess.
• Platform-specific features. Be able to specify features for target-platform-specific dependencies, and have them enabled only when targeting that platform.
• Mutually exclusive features. Projects sometimes have features that conflict with one another, but this currently cannot be expressed.

Priority: I think "features" work should be a high priority because they are one of the most commonly reported issues/requested enhancements in the issue tracker today. Of all the categories, I think splitting dependency kinds would have the most benefit since it is the most difficult or impossible to work around today.

Current status: There are a few old RFCs, and tons of discussion and ideas in the issue tracker, and a few implementation attempts (and -Z package-features is unstable). However, I think taking a step back and examining the overall strategy for features would be a good idea before diving into specific new RFCs.

Implementation: I have a rough idea of the implementation issues, which doesn't seem too difficult to me. I think the design phase will be the most difficult — enhancing in a backwards-compatible fashion with a clean UI, avoiding extra compiles of crates when not wanted, etc.

I'm eager to make forward progress, and I'd love to hear from anyone who has thoughts about this. One area that I have the greatest uncertainty about is how to approach these challenges in a backwards-compatible manner.

[Eh2406]

automatic features

I don't know if this is what you had in mind, but it would be nice to have "features that automatically activate if there dependencies are met". Like if serdy is in the dependency tree then I will have a dependency on it and will provide its types, but if no one else uses it then dont bother. I don't know how possible this idea is with the resolver. I was going to start investigating after pub/priv deps but pub/priv is being difficult. In either case we should leave room in the new interface.

[ehuss]

Yea, essentially something like rust-lang/rfcs#1787.

[nrc]

ping @dwijnand, @joshtriplett, @Eh2406

some questions:

• what is the status of pub/priv deps?
• what would the manifest format look like with all these things implemented? Is there much overlap either in the manifest format, the implementation, or the use case?

[Eh2406]

• what is the status of pub/priv deps?

The RFC is accepted, so a lot of the details are planned out. The implementation has 3 part:

1. Extending the privacy system in rustc to lint on using private deps in the public interface. This should not be to hard as there is an existing lint for private types in the public interface. Not that I know how to do it, nor that any one is eager to make it happen. @alexcrichton reluctantly offer to do it iif all the other parts are completed.
2. Add it to the Cargo.toml and the Index and publishing. This is not done, but it is just plumbing, so when we need to we can make it happen.
3. Adding it to the resolver. I am working on this at Tracking issue for RFC 1977: public & private dependencies, as it relates to the resolver cargo#6129, I have a WIP branch that I am confident is only giving correct answers! The Proptest did a great job of proving that was harder than I imagined. Unfortunately, it has problems. Proptest quickly points out that it doesn't always find a solution when one is available. I am thinking on how to fix that. I would love to talk about the details to anyone (that does not run away fast enough) but I doubt it will help the conversation here.

I think pub/priv deps is pretty orthogonal to the other suggestions here.