Tracking Issue for weak dependency features

[ehuss]

Summary

Original issue: #3494
Implementation: #8818
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#weak-dependency-features

-Z weak-dep-features will enable "weak" dependency features, whereby dep_name?/feature_name syntax in the [features] table will not automatically enable the dep_name dependency (unlike the dep_name/feature_name syntax which always enables dep_name). This just indicates that the feature on that dependency should be enabled if something else enables that dependency on this package.

Unresolved issues

• Bike shed the syntax. We've discussed various variants:
  • dep_name?/feat_name
  • ?dep_name/feat_name
  • dep_name?feat_name
  • Or maybe something more verbose like {dep="dep_name", feature="feat_name", enable-dep=false}
  • Or a more verbose string format, like if-dep:dep_name/feat_name (read this as "if dependency foo then enable feature bar").
  • Concerns:
    • Too verbose, and people may be less likely to use it.
    • Terse ? format means people will have to look up what it means, and searching for punctuation is difficult.
    • Interaction with org_name/pkg_name syntax, which could contribute to the punctuation soup.
• Possibly make this the default behavior for dep_name/feat_name syntax on an edition boundary. A concern is that this is not an (easily) rustfix-able change.
• Figure out how to deal with breakage of Cargo versions older than 1.19. Resolved in Add schema field and features2 to the index. #9161.

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.

[mehcode]

Possibly make this the default behavior for dep_name/feat_name syntax on an edition boundary [...]

I think is the best option if we can make it work.

foo = [ "bar/baz" ] # just /baz if bar is activated
foo = [ "bar", "bar/baz" ] # bar and bar/baz

[est31]

@mehcode I think the issue is that due to the way it's built, rustfix knows nothing about Cargo.toml, thus cargo fix does neither. I guess the solution would be to extend cargo fix to also change Cargo.toml. That would work but is non-trivial. I think https://github.com/matklad/tom might be useful here.

[KamilaBorowska]

In my opinion we shouldn't have a syntax for this feature, instead a programmer could use "foo/bar" directly. There is a compatibility concern by doing so, but it could be dealt with by providing a warning when a dependency feature is used without depending on a dependency itself.

For example, in this case there would be no warning as feature b depends on lib.

a = ["lib"]
b = ["a", "lib/feature"]

However, without depending directly or indirectly on a dependency there would be a warning.

b = ["lib/feature"]

Then in a future edition of Rust the behaviour would change so that having "lib/feature" feature wouldn't enable "lib" feature.

[alexcrichton]

@xfix FWIW we wanted to avoid that because it means the meaning of a/b differs depending on whose lockfile you're looking at. We thought that would be too confusing because a/b has been a feature of Cargo for so long. That's what pushed us to find a different syntax.

(although what you describe I believe is technically feasible, our hesitation was just about the confusion of having the same syntax mean two different things depending on the context)

[est31]

differs depending on whose lockfile you're looking at.

@alexcrichton you mean Cargo.toml? lockfiles can be shared by crates of different editions and they also don't have the a/b syntax anywhere.

[KamilaBorowska]

I think having the same syntax could be balanced by having a warning when using the syntax in older editions - so there would be only a single behavior that doesn't cause a warning. Also, I think the behaviour of a/b feature enabling a optional dependency is somewhat surprising.

Add to that we can implement a warning now, we don't have to wait for Edition 2021 or something like that - a warning could be dealt with by replacing "a/b" with "a", "a/b" - this works even in Rust 1.0.

From a list of 30 most popular dependencies (by recent downloads) on crates.io I found that the 2 crates unintentionally enable optional features.

• rand unintentionally enables rand_chacha with std feature

  std = ["rand_core/std", "rand_chacha/std", "alloc", "getrandom", "libc"]

• syn unintentionally enables quote with proc-macro feature

  proc-macro = ["proc-macro2/proc-macro", "quote/proc-macro"]

On the other hand log has a feature called kv_unstable_sval which enables sval dependency by saying sval/fmt.

kv_unstable_sval = ["kv_unstable", "sval/fmt"]

However log could easily deal with a suggested warning by doing the following instead.

kv_unstable_sval = ["kv_unstable", "sval", "sval/fmt"]

In fact, rand_core is already doing something similar. It technically doesn't need to specify "getrandom", but does it anyway.

std = ["alloc", "getrandom", "getrandom/std"]

[alexcrichton]

Er yes I meant the manifest, not the lock file. @xfix that's perhaps plausible to simply warn, but that's also a massive task to force the entire Rust community to relearn a feature they already know. There's a very real cost to that which isn't present if we pick a new syntax.

[est31]

Personally I think that warning or not, switching it without an opt-in of either an edition or special syntax is a violation of Rust's stability guarantees. I support the idea of changing the syntax on a edition boundary, but I think this feature is too useful to wait for a new edition, or be even blocked by a discussion about the syntax :). First it can be introduced with the new custom syntax, then later one can decide whether the new edition should switch to it by default. Also there is the question of interactions between the RFC to do workspace sharing of information and having heterogenous edition choices inside a workspace.