Exclude files only useful for development from published crates

[decathorpe]

This came up while packaging py / python-launcher for Fedora Linux.

The crates published to crates.io contain a few files that look like they're only ever useful for upstream development or your release process, and so they can be excluded from published crates (making upload / download sizes smaller, etc.).

• /changelog.d: changelog entry fragments, only used for your release process
• /docs/readme/: readme file template, only used during development (?)
• /release/: collection of python files / scripts to handle release process
• /dodo.py: not sure what this is, but looks like it's used solely for release process purposes

This PR introduces an explicit list of files to be included in published crates:

• Cargo.toml is always implicitly included
• /src/, /tests/, (essential metadata and source code)
• README.md and CHANGELOG.md (documentation that's useful for "end users")
• shell completions
• the control flow diagram referenced from the README.md file, and the manual page for py.1
• the LICENSE file

This change has the nice benefit of making the compressed crate ~60% smaller (32 KB vs. 100 KB).

[brettcannon]

@decathorpe Thanks for the PR! I just got back from vacation so I have a bit of a backlog to get through, but I will have a look at your PR at some point (and I suspect I will accept it in some form).

Do you mind adding a changelog entry about the change?

[decathorpe]

Sure, I'll polish up the PR tomorrow. Thanks!

[hroncok]

FWIW I think the PR description would be nice in the commit message directly, so it is preserved.

[brettcannon]

Documentation on include https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields (to make it easier when I review the PR).

And the dodo.py file is for https://pydoit.org/.

[brettcannon]

@decathorpe would using a build script (i.e. build.rs) and removing the generated files be more or less helpful to your packaging (thinking about this in #150 )? For instance, I could make man page generation be via build.rs but then that would require having pandoc installed to make the man page work.

My guess is it wouldn't be much of a win, but I thought I would double-check.

[decathorpe]

Just including the files that are meant for "end users" is the easiest solution, I think. Any build script or sophisticated machinery is probably over-engineering a solution for a non-problem.

[brettcannon]

Very minor stuff and a question as to why some things were left in.

[brettcannon]

Thanks for the patience with answering all of my questions!

[decathorpe]

No problem, thanks for accepting my changes! :)