RFC: Cargo feature visibility (private/public)

[tgross35]

Rendered

RFC for feature-visibility
RFC goals: add a way to make Cargo features private

This was split from #3416

[features]
foo = { enables = [], public = false}

This would resolve rust-lang/cargo#10882

[epage]

If we strip them, that affects a couple use cases

• When helping with managing the feature graph, you might want to cfg based on this
• Activating debug features in clap or winnow via --features winnow/debug

[tgross35]

In that case, do you think it is worth including the index change as part of the MVP?

[epage]

The index change can be fairly minor

• Add a new private-features = [<name>, ...] entry
  • private because those should be in the minority and keeps the index smaller
• Only allow them to be used when MSRV is high enough
  • Question is what to do when MSRV is unset.
  • It might be of interest for us to add other MSRV fields, like published-rust-version to record what version of rust was cargo publish done in and a calculated-rust-version that isn't as precise as rust-version but is a minimum value based on things like setting the edition or using private features
  • Alternatively, we could just make it a warning: "Hey, your rust-version is unset, if you publish with private features, older versions of cargo can use them and then will. break on upgrade"

[weihanglo]

I can foresee people requesting for workspace public/private features. How does this RFC interact with Cargo workspaces?

[weihanglo]

the link is broken

[tgross35]

Thanks, a lot of links got reshuffled when I split the RFCs. I will fix this

[weihanglo]

It's not clear what cfg means here. I assumed it is the cfg attribute and the cfg macro. Could you expand and link to their doc respectively?

[tgross35]

I kind of forgot the exact context here, this comes from Ed's comment at #3416 (comment) and the two following comments. Also #3416 (comment).

Do you have any ideas for how to improve the wording?

Thank you for taking a look by the way

[epage]

If we strip the private features then when cargo does a build, it won't tell rustc about private features and if you do #[cfg(feature = "private-foo")] then it will never evaluate to true

[tgross35]

I can foresee people requesting for workspace public/private features. How does this RFC interact with Cargo workspaces?

Do you mean crates within a workspace wanting to use private features for other crates in the workspace? If so, I previously had a --allow-private-features flag as part of this proposal that would cover that, but I removed it recently. Do you have any suggestions for how we could handle this?

[ijackson]

Do you mean crates within a workspace wanting to use private features for other crates in the workspace? If so, I previously had a --allow-private-features flag as part of this proposal that would cover that, but I removed it recently. Do you have any suggestions for how we could handle this?

How about public = "workspace"

[ijackson]

I think stripping features out on publish is a bad idea. I haven't thought through all the ramifications, but having different behaviour for the crates.io tarball and for the actual source code from git seems like a beartrap.

I'm not sure why any changes are needed to the infrastructure for initial support. The infrastructure would display the features and convey them to clients, and it would be up to clients to enforce them.

However, we do need something that a user of this feature can put in their crate that will prevent old versions of cargo from failing to honour the public flag.

[epage]

FYI this is already being discussed some in #3487 (comment)

As for why infrastructure is needed is a "it depends". There are a lot of ways to slice and dice things to possibly make things work.

When dependency resolution happens, it works off of a Summary of the Cargo.toml that is stored inside the Index. If we want to prevent use when resolving dependencies, it must be present in the Summary. We could instead do a second pass on the dependency tree, checking for use of private features. This would likely break down quickly as we don't know why features are enabled (other features from within the package or the caller). Setting that aside, this would require downloading and extracting of .crate files which we normally do lazily. So we either lose the lazy approach or we only do the verification for what is currently being built which means the answer won't always be visible but you need to test every platform and feature combination.

[epage]

Do you mean crates within a workspace wanting to use private features for other crates in the workspace? If so, I previously had a --allow-private-features flag as part of this proposal that would cover that, but I removed it recently. Do you have any suggestions for how we could handle this?

How about public = "workspace"

A workspace level feature can work fine locally but fails on publish as we have no concept of workspaces in the registry. That is a whole system to design that seems out of scope of this RFC and at most should be left to a future possibility.

[epage]

Should we expand this to all required-features? That way we can do things like have private bins for testing purposes

[epage]

What about

• cargo install? Is that more like a [dependencies] entry and forbidden or like cargo check --features and allowed?
  • Does the answer change if we are doing the install from registery vs git vs path?
• What about path dependencies? Should we allow workspace members to have access to private details?
  • If not, what about a path = "." dependency? These are used in dev-dependencies to enable features specific to testing

The answer to these isn't necessarily "yes" or "no" but can also be "not yet, we'll error for now and re-evaluate in the future" at which point it should be in the future possibilities.

[epage]

feature name should be updated

[epage]

This RFC is blocked on feature-metadata