Cargo structured syntax for feature dependencies on crates #3663
Conversation
This RFC extends Cargo's structured table form of features to include a `deps`
key, to unambiguously specify packages the feature depends on without having to
use the `dep:foo` microformat.
```toml
[features]
myfeature = { deps = ["some-crate", "another-crate"] }
# This is equivalent to `myfeature = ["dep:some-crate", "dep:another-crate"]`
# This can also be written in shorthand form:
myfeature.deps = ["some-crate", "another-crate"]
```
joshtriplett
added
the
T-cargo
|
|
||
| In the future, we could also provide an alternative to the | ||
| `crate-name?/feature-name` microformat, or alternatively we could migrate | ||
| towards making `crate-name/feature-name` mean that in a future edition. This |
There was a problem hiding this comment.
My -1 is mainly because of putting pkg?/feat and pkg/feat into "future possibilities" 😕. Without "structurizing" DepFeature, the introduction of deps key puts the transition in an awkward incomplete state as you still need to use the microformat to enable features of a dep. Better just postpone if it's not ready.
I don't think actually defining DepFeature here makes the RFC harder to review, this RFC is already short enough.
There was a problem hiding this comment.
as you still need to use the microformat to enable features of a dep
Agree. Not considering DepFeature as a whole may end up having three ways to define that. It's better to one or the other, not a combination of them.
# old
[features]
tracing = ["valuable", "log/std"]
# this
[features]
tracing = { enables = ["valuable", "log/std"], deps = ["log"] }
# future maybe?
[features.tracing]
enables = ["valuable"]
deps.log = ["std"]
There was a problem hiding this comment.
I agree from at least a specific perspective. For me, the thing that has bothered me is the inconsistent way of referring to dependencies:
feature_name
dep:dep_name
dep_name/feature_name
I feel like this should be
feature_name
dep:dep_name
dep:dep_name/feature_name
(this is worse with implicit features because deps and features get muddled but 2024 fixes that)
|
|
||
| However, if a crate uses the `deps` key, it should consistently use the `deps` | ||
| key for all feature dependencies on crates, rather than using a mix of `deps` | ||
| and `"dep:"`. (Cargo may choose to warn about mixing the two.) |
There was a problem hiding this comment.
Since this is a brand-new syntax, believing that it could be an error.
A future possibility is that we ship this as a hard error, and later become configurable via cargo-lints.
|
|
||
| In the future, we could also provide an alternative to the | ||
| `crate-name?/feature-name` microformat, or alternatively we could migrate | ||
| towards making `crate-name/feature-name` mean that in a future edition. This |
There was a problem hiding this comment.
as you still need to use the microformat to enable features of a dep
Agree. Not considering DepFeature as a whole may end up having three ways to define that. It's better to one or the other, not a combination of them.
# old
[features]
tracing = ["valuable", "log/std"]
# this
[features]
tracing = { enables = ["valuable", "log/std"], deps = ["log"] }
# future maybe?
[features.tracing]
enables = ["valuable"]
deps.log = ["std"]
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| - This adds minor incremental complexity to parsing the manifest, both for | ||
| Cargo itelf, and for third-party tools that parse the manifest without using | ||
| Cargo's parser. | ||
|
|
There was a problem hiding this comment.
We're providing two ways for the user to do something which can cause extra confusion.
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| - This adds minor incremental complexity to parsing the manifest, both for | ||
| Cargo itelf, and for third-party tools that parse the manifest without using | ||
| Cargo's parser. | ||
|
|
There was a problem hiding this comment.
Unless we are saying to always use the "detailed" (table) format, the user has to translate between two syntaxes as their use case grows.
|
|
||
| This has created somewhat of a microformat within the dependencies list, and | ||
| this microformat adds complexity compared to other parts of the Cargo manifest, | ||
| which distinguish different kinds of things via different keys or sections. (By | ||
| way of example, we have `dev-dependencies` and `build-dependencies`, rather | ||
| than a microformat like `dependencies."build:xyz"`.) | ||
|
|
||
| Now that [RFC 3416](https://github.com/rust-lang/rfcs/pull/3416) has defined a | ||
| structured table form for defining features, this RFC takes a first step | ||
| towards providing structured equivalents in place of the microformat. |
There was a problem hiding this comment.
We also have the cfg microformat.
Overall, I feel like judicious use of microformats extends what a standardized grammar allows and can enhance the format. For me, this motivation feels very weak and the change possibly a net negative while encouraging a wide ecosystem churn that I'm not seeing the pay off for.
|
[edit: Comment should have been to 3416, sorry for the noise, thanks for the clarification in #3663 (comment)] |
|
Note that the table syntax is independent of this and its RFC has been merged. There is a description RFC up. |
| feat1 = { enables = ["feat2", "feat3"], deps = ["crate1"] } | ||
| feat2 = { deps = ["crate2"] } | ||
| feat3.deps = ["crate3"] | ||
| """ |
There was a problem hiding this comment.
Is this a typo?
| """ |
This RFC extends Cargo's structured table form of features to include a
depskey, to unambiguously specify packages the feature depends on without having to
use the
dep:foomicroformat.This incremental RFC was inspired by the incremental, easier-to-review RFCs
currently being used for other individual pieces of the structured table format
for features.
Rendered