{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiajhdk47oq2dwc4o7aoydxk7awlan7ughyyqrku3da7aclrqq5kpy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgtrqsjfnei2"
  },
  "path": "/t/optional-features-are-part-of-the-crate-the-project-should-say-so/24069#post_14",
  "publishedAt": "2026-03-11T22:38:31.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "pacak:\n\n> You can add something like in your `Cargo.toml`\n>\n>\n>     [dev-dependencies]\n>     mycrate = { path = \".\", features = [\"stuff\", \"disabled\", \"by\", \"default\"] }\n>\n\nepage:\n\n> Not finding the issue right now but this can get confusing results in some cases.\n>\n> This also makes it more difficult to test without features which can be important in some cases.\n\nA more flexible way to get this same effect today is to add another package in the same workspace which has this dependency. Then, builds using the default set of workspace members will have the features, and `cargo test -p mycrate` will not.\n\nBut it might not be desirable to apply the features to all default-members builds, only editing. So, it might make sense for Cargo to offer a feature list, not as a config, but as a _workspace_ property or properties — some sort of `workspace.default-features-for-development`. This would have the advantage over config that the features apply exactly to the workspace (which is the scope at which feature names mean something) rather than the current directory.",
  "title": "Optional features are part of the crate — the project should say so"
}