cargo package should warn binary files by default #4413
Labels
A-diagnostics
Area: Error and warning messages generated by Cargo itself.
C-enhancement
Category: enhancement
Command-package
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Comments
|
E.g. this bugzilla patch, produced via |
|
Sounds like a good idea to me! |
|
Another bloating which could be avoidable if we have such warning: dropbox/rust-brotli#8 |
|
Related issue about packaging a binary on purpose: serde-rs/serde#2538 |
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 31, 2024
### What does this PR try to resolve? This adds a special case for checking source files are symlinks and have been modified when under a VCS control This is required because those paths may link to a file outside the current package root, but still under the git workdir, affecting the final packaged `.crate` file. ### How should we test and review this PR? Pretty similar to #14966, as a part of #14967. This may have potential performance issue. If a package contains thousands of symlinks, Cargo will fire `git status` for each of them. Not sure if we want to do anything proactively now. The introduction of the `PathEntry` struct gives us more room for storing file metadata to satisfiy use cases in the future. For instances, * Knowing a source file is a symlink and resolving it when packaging on Windows * #5664 * #14965 * Knowing more about a file's metadata (e.g. permission bits from Git) * #4413 * #8006 * Provide richer information for `cargo package --list`, for example JSON output mode * #11666 * #13331 * #13953
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've seen multiple times that some images which is used in README only is included into crate package, e.g. bindgen contains a 1.3MB PNG, and dtoa contains a 68KB PNG.
I believe binary files in general are not useful in packages. They should be excluded or at least warned by default. People should still be able to explicitly specify binary files if necessary, though.
The text was updated successfully, but these errors were encountered: