Following on from #981 (comment):

I did python3 setup.py sdist bdist_wheel and compared dist/black-19.3b1.dev84+g0a19a5d.tar.gz with black-19.3b0.tar.gz from https://pypi.org/project/black/#files.

$ ls -l dist/black-19.3b1.dev84+g0a19a5d.tar.gz
-rw-r--r--  1 hugo  staff   1.0M  6 Sep 08:48 dist/black-19.3b1.dev84+g0a19a5d.tar.gz
$ ls -l /tmp/Downloads/black-19.3b0.tar.gz
-rw-r--r--@ 1 hugo  wheel   152K  6 Sep 08:48 /tmp/Downloads/black-19.3b0.tar.gz

Should some excludes be added to MANIFEST.in?

Good point, @hugovk! The ideal solution would be for setuptools_scm to not hijack the file_finders operations, unless explicitly asked, but since that is beyond us we have to change the MANIFEST file like you suggested. I found that you already went through this, so I will leave the links as clues to fix this:

• setuptools_scm includes EVERYTHING in Git unless explicitly excluded hugovk/osmviz#30
• setuptools_scm includes EVERYTHING in Git unless explicitly excluded hugovk/pypistats#63

Also slides 11-13 in https://blog.ionelmc.ro/presentations/packaging/#slide:11 might be useful.

I think it is good that you pointed it out @hugovk as this is an important difference.

One should bear in mind that this behavior is not a bug in setuptools-scm it is an intentional design feature and is discussed in pypa/setuptools-scm#190 and Python setuptools' MANIFEST.in explained. tl;dr In the issue, Jason Coombs explains

In my opinion the sdist is meant to be more than just a copy of the Python functionality, but is meant to be a distributable copy of the source code. I would expect someone to be able to download the sdist, extract it, and develop on the project much like they would if cloning the repo. These sdists are used by downstream packagers (Debian, RedHat) to run tests and other validation on them.

This frees developers from dealing with MANIFEST.in potentially making errors. In our particular case, the listing of the sdist (that is shown) does not include docs which should probably be present there and .github contains CODE_OF_CONDUCT.md which I think is nice to have it.

Thanks for the comments @hugovk and @ashwinvis. I prefer to leave it compatible with PyPA but let's see what the maintainers think.

This is definitely a lot more elegant. @zsol what do you think?

Also, there's a minor merge conflict.

I skimmed through it during the weekend and looked good to me. Haven't had time to review in depth yet. I'm happy with the approach though 👍

Thanks!