Integrate functionality from check-manifest

Originally reported by: freakboy3742 (Bitbucket: freakboy3742, GitHub: freakboy3742)

---

A common problem with Python packaging is creating and maintaining an accurate MANIFEST/MANIFEST.in file. It's easy to add a new submodule or piece of documentation, forget to include it in your MANIFEST, upload a release to PyPI, then have to issue a new point release to correct the problem.

check-manifest is a package that addresses this problem. If you run the command, it builds a source distribution and checks to see if there are files in the source directory that aren't in the package distribution; if there are missing files, it suggests MANIFEST.in rules that would correct the omission. It can also be used to generate an initial MANIFEST.in for a project.

In my opinion, check-manifest is sufficiently useful functionality that it warrants being part of setuptools itself.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/57

Original comment by freakboy3742 (Bitbucket: freakboy3742, GitHub: freakboy3742):

---

The working parts of check-manifest is a single source file, so it should be fairly easy to integrate as a setuptools command.

There's a potential licensing issue. check-manifest is released under GPLv2+. However, the author indicates in the source code that they're open to MIT as a licensing option. They might be open to PSF licensing too.

Original comment by freakboy3742 (Bitbucket: freakboy3742, GitHub: freakboy3742):

---

Original author has just given permission over twitter; I'll see if I can get him to log in here and give permission formally.

Original comment by mgedmin (Bitbucket: mgedmin, GitHub: mgedmin):

---

MIT is fine with me, but check-manifest also contains code written by Steve Myint (git@stevenmyint.com). I haven't received his permission yet.

I'm (ab)using mgedmin/check-manifest#12 to track the licencing situation.

Original comment by freakboy3742 (Bitbucket: freakboy3742, GitHub: freakboy3742):

---

Based on this comment it appears that all contributors are OK with MIT licensing of check-manifest content.

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

It doesn't seem unreasonable to include check-manifest in setuptools, though it's not immediately obvious to me that it belongs in setuptools. I have some additional questions as well. If it were incorporated, where would the code be maintained? Would @mgedmin maintain it in the setuptools codebase or would it also be maintained in the separate project?

I'm actually more inclined than I used to be to have more separation between projects, to allow them to be separately developed and be loosely coupled.

At the very least, check-manifest should first implement a 'distutils.commands' entry point, demonstrating how it might work when integrated with setuptools. Or would it not implement a distutils command (e.g. python setup.py check-manifest)?

Another concern is 'argparse'. Check-manifest imposes additional install requirements. I'm not sure what effect having install requirements on setuptools would have to bootstrapping setuptools.

Given these considerations, I'm slightly inclined to decline the offer to integrate check-manifest with setuptools, but I'm still open to the idea and am willing to be convinced.

Original comment by mgedmin (Bitbucket: mgedmin, GitHub: mgedmin):

---

check-manifest is a crutch to work around some non-intuitive behavior in setuptools. Wouldn't it be better to fix the non-intuitive setuptools behavior instead?

Specifically:

• When setuptools can detect files in your VCS, it puts them in sdist. When it can't, it silently doesn't. The silent failure is unpleasant, wouldn't it be better to explicitly ask for VCS files by passing an argument to setup.py and then fail with an error if the right setuptools VCS plugin is not installed or is outdated and no longer recognizes the SVN working tree format of the month, or if you run setup.py on a tarball snapshot of a VCS revision downloaded from GitHub instead of using a checkout?
• Setuptools looks at old *.egg-info/SOURCES.txt and includes those files. When is this useful? Can we get rid of this heuristic?

Of course there should be some thought put into backwards compatibility, because I'm sure there are people who rely on the current behavior.