{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigteb5tqs2ayaf26jhigqkweofg4c7spn4xy5vc67lduvv4o3sfyu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgzupew6x342"
  },
  "path": "/t/optional-features-are-part-of-the-crate-the-project-should-say-so/24069?page=2#post_24",
  "publishedAt": "2026-03-14T16:14:05.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "epage:\n\n> We will likely never directly support `.cargo/config.toml` fields in `Cargo.toml`. Instead, we will need to look at how they should be abstracted in `Cargo.toml`.\n\nThis plan means package/workspace `.cargo/config.toml` will continue to need to exist indefinitely. I don't like that.\n\nWhat would be so bad about moving everything, and I really do mean _everything_ , from `.cargo/config.toml` to `Cargo.toml`, _right now,_ so that we can deprecate the _existence_ of `.cargo/config.toml` in packages and workspaces as soon as possible?\n\nYou could still migrate these settings to a better schema _within_ `Cargo.toml`, later, probably on a setting-by-setting basis. It seems to me it would go more smoothly overall.",
  "title": "Optional features are part of the crate — the project should say so"
}