{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia6ukwvijxt4bnkqfumhpxfzd3ehjmstxfrkrtzd3v7tydhz4dn74",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk55numpjml2"
  },
  "path": "/t/pre-rfc-cargo-package-should-include-fewer-files-by-default/24188#post_6",
  "publishedAt": "2026-04-23T02:29:22.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "kpreid:\n\n> I also think that it would be valuable if `cargo publish` verification _ran tests_ to reduce the chances of publishing a broken-as-published package — all the more so if the default file exclusion rules were stricter.\n\nNo, thank you. Crates may have more than \"the machine I use to publish with the Rust toolchain I happened to publish from\" as interesting targets where the tests need to pass. And without build isolation, you still have the \"oops, works on my machine\" problem. I have our publishes done in a CI job that depends on all relevant configurations testing successfully; I don't think `cargo publish` is ever going to understand that for anything beyond \"needs to work on a Linux\"-scoped crates.\n\nIf the \"the build is sensitive to this file\" worked better (I don't have the issues handy, but basically if you use them, Rust's _default_ file collection is completely ignored, so you have to implement it just to add one file to the list), then I think `cargo publish` could at least rely on `build.rs` and `cargo check` reporting. But again, if a file is only used on Windows, a pass on Linux is going to miss it.",
  "title": "[Pre-RFC] `cargo package` should include fewer files by default"
}