We have enough debate about are things required by policy in Debian that, in my opinion we sometimes lose track of why things are a good idea to begin with. I just had a conversation via GitHub with a potential upstream developer (I’m looking into packaging something he developed) that reminded me about some of the reasons some of the non-code we try to ship are a good idea.
This is a Python based project. References to MANIFEST.in (manifest) translate to “extra files to put in the tarball” and references to sdist mean the source tarball.
UPSTREAM: Thanks for the pull request. Is there any place where I can find more information about this manifest file, and why it’s important to have one?
ME: There are two files (LICENSE and CHANGELOG) that it would be good to have in the sdist, each for their own reason:
We want LICENSE because since Debian distributes both source and binary we want a copy of the exact license for the code in our source distribution so the the requirements are clear and self-contained. I think this is a good general practice anyway.
We want CHANGELOG so we can ship it in the package documentation to enable users to see what has changed over time with the package.
MANIFEST.in is just a way to add files to the sdist (it’s the normal way in distutils). I’m not that versed in setuptools myself, but I do know there are other ways to do it. What’s important (at least from our point of view) isn’t the MANIFEST.in file itself, but the added files it would add to the sdist.
If the MANIFEST.in isn’t shipped with the sdist, then a downstream distributor that modified the package might get a different result. I believe it’s a good general practice to include all the components of a package build system when you ship it.
That’s probably way more information than you wanted …