RFC: Cargo feature visibility (private/public) #3487
Conversation
compiler-errors
added
the
T-cargo
These are meant to apply simple feedback that wouldn't change the author's intent.
text/3487-feature-visibility.md
Outdated
| This feature requires adjustments to the index for full support. This RFC | ||
| proposes that it would be acceptable for the first implementation to simply | ||
| strip private features from the manifest; this meanss that there will be no way | ||
| to `cfg` based on these features. |
There was a problem hiding this comment.
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
debugfeatures inclaporwinnowvia--features winnow/debug
There was a problem hiding this comment.
In that case, do you think it is worth including the index change as part of the MVP?
There was a problem hiding this comment.
The index change can be fairly minor
- Add a new
private-features = [<name>, ...]entryprivatebecause 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-versionto record what version of rust wascargo publishdone in and acalculated-rust-versionthat isn't as precise asrust-versionbut 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"
| This RFC describes a new key under `features` in `Cargo.toml` to indicate that a | ||
| feature is private. | ||
|
|
||
| Please see the parent meta RFC for background information: [`feature-metadata`]. |
There was a problem hiding this comment.
Thanks, a lot of links got reshuffled when I split the RFCs. I will fix this
| This feature requires adjustments to the index for full support. This RFC | ||
| proposes that it would be acceptable for the first implementation to simply | ||
| strip private features from the manifest; this means that there will be no way | ||
| to `cfg` based on these features. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>
Do you mean crates within a workspace wanting to use private features for other crates in the workspace? If so, I previously had a |
How about |
| This feature requires adjustments to the index for full support. This RFC | ||
| proposes that it would be acceptable for the first implementation to simply | ||
| strip private features from the manifest; this means that there will be no way | ||
| to `cfg` based on these features. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
| - Referenced in `[[bench]]` and `[[test]]` target `required-features` | ||
| - Using the feature on the command-line is allowed |
There was a problem hiding this comment.
Should we expand this to all required-features? That way we can do things like have private bins for testing purposes
| Attempting to use a private feature in any of the forbidden cases should result | ||
| in an error. Exact details of how features work will likely be refined during | ||
| implementation and experimentation. |
There was a problem hiding this comment.
What about
cargo install? Is that more like a[dependencies]entry and forbidden or likecargo check --featuresand 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 indev-dependenciesto enable features specific to testing
- If not, what about a
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.
| @@ -0,0 +1,165 @@ | |||
| - Feature Name: feature-metadata | |||
There was a problem hiding this comment.
feature name should be updated
epage
added
the
S-waiting-on-author
| This RFC describes a new key under `features` in `Cargo.toml` to indicate that a | ||
| feature is private. | ||
|
|
||
| Please see the parent meta RFC for background information: [`feature-metadata`]. |
There was a problem hiding this comment.
This RFC is blocked on feature-metadata
Rendered
RFC for
feature-visibilityRFC goals: add a way to make Cargo features private
This was split from #3416
This would resolve rust-lang/cargo#10882