{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifltz453kfuojcmv7jd7fowajk7mnc5ldngohwuovgpdf3vouwi4e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk7arsrfrub2"
  },
  "path": "/t/pre-rfc-cargo-package-should-include-fewer-files-by-default/24188#post_12",
  "publishedAt": "2026-04-23T23:49:52.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I second the supply chain concerns. The \"Jia Tan\" attack has shown that test files may not be harmless.\n\nThe crates-io ecosystem is super useful, but when Rust is used at high value targets it requires reviewing all crates, and this is a laborious process. The fewer files the better, especially avoiding unreviewable binary data.\n\n### Tests in tarballs\n\nThere are pros and cons of having tests in the tarballs, but the issue is contentious, because Cargo gives mixed signals about this.\n\nCargo including `tests/` dir by default may suggest that tests belong in the published tarballs.\n\nOTOH Cargo doesn't have an option to run tests from a crates-io crate. To me this is a sign that it's not an expected workflow.\n\nCargo does not run tests when publishing a package either. `cargo publish` runs a build, but doesn't run tests, doesn't even check if the tests build. This kinda says that it's important that the lib and bin targets build, but other targets are not relevant in packages.\n\nAs a crate author I'm uncomfortable with this unclear situation, because:\n\n  * I exclude files from my packages, but I never check whether the tests still work after packaging (it's a real concern when test assets or test helper tools are at workspace level, not inside individual crates). I may have packages with broken tests, while there are users who expect my tests to work and may be wasting time investigating the failures.\n\n  * Even when tests aren't broken, but a package is published without the `tests/` dir, consumers of the package may get a false assurance that \"all\" tests pass, while they get only a fraction of small unit tests left in `src/`\n\n\n\n\nSo having a clear stance and workflow support from Cargo would set right expectations for both crate authors and users.\n\nI'm leaning towards excluding all test files from packages to save bandwidth, and I'd prefer Cargo to exclude `tests/` by default to make it clear that packages are not meant to be self-testable (packages are downloaded way way more times than they're tested via Crater or packaged in a Linux distro.)\n\nBut if Cargo took a stance that tests should be working in packaged crates, it should add features for verifying tests in tarballs, so I could ensure I publish crates with working tests.\n\nThe solution doesn't have to be simply between including all or excluding all. There's a ton of possibilities in the middle. For example, Cargo could support a dedicated \"test_data\" directory (or `include-when-testing` globs in `Cargo.toml`) which would be saved in the published tarball, but _not_ extracted when only building the crate as a dependency. This would remove the worry that test files can smuggle a hidden payload, but still support users who extract tarballs manually for testing.\n\nA dedicated dir for test data would remove the guesswork during packaging, and allow being much more selective about including files from elsewhere.\n\nOr Cargo could exclude tests and most other files from the tarballs, but when publishing check that the repo URL is valid and the commit hash can be fetched. This would help users testing the package obtain the whole workspace with all the helpers and assets in a correct version (this is already possible in theory, but not reliable enough due to missing/stale repository URLs and unpushed commits)",
  "title": "[Pre-RFC] `cargo package` should include fewer files by default"
}