External Publication
Visit Post

[Pre-RFC] `cargo package` should include fewer files by default

Rust Internals [Unofficial] April 22, 2026
Source

epage:

If we go by extension, this will likely miss a lot of test data that people won't notice is missing because they don't run cargo test on the package. I wonder if we should exclude test/bench build targets

  • Excluding test targets would not affect the presence of #[test]s in the lib sources, so it is not a means to avoid publishing non-functional tests. (Though I imagine it is more common for tests which need external data files to be test targets.)

  • Most packages’ tests do not take up significant amounts of disk space (or have any non-code files at all). Keeping tests, when they are cheap, is valuable for “wait, did this published package ever work as intended? If so, on which Rust versions?” kinds of investigations. 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.

So, I think that tests which have data files (large or not) should be treated as a non-default situation which you might have to configure the manifest for.

That is, I’d prefer the following behaviors:

* Files not known to be likely part of any target’s source code (or licenses, etc) are excluded from the package by default.
* `cargo publish`/`cargo package` runs tests, not just a build.
* If your tests don’t work under these default conditions, you are encouraged to _explicitly configure_ excluding the relevant tests, both code and data, from the package.
  * Having such explicit configuration available (perhaps something like `test.*.publish = false`) would also benefit users who would like to exclude _all_ test files, but currently can’t do so because it leaves the manifest with a `[[test]]` entry missing its crate root source file (which, IIRC, is currently an error whether or not the test is being run).

Another possibility might be to require more explicit inclusion/exclusion:

  • Have default rules for which files should be included (source files, LICENSE*), extended by package.include
  • Have default rules for which files should be excluded (.*), extended by package.exclude
  • Error if any files are found that is not covered by either

Discussion in the ATmosphere

Loading comments...