Python分发的用例有哪些？
我正在为我写的Python包开发一个分发版本，以便能把它发布到PyPI上。这是我第一次接触distutils、setuptools、distribute、pip、setup.py这些东西，感觉学习起来比我想象的要难很多 :)
我在setup.py中通过data_files参数把一些测试数据文件包含到压缩包里时遇到了一些麻烦，直到我看到这里的一个帖子提到了MANIFEST.in文件。那一刻我意识到，使用MANIFEST.in包含在压缩包/zip文件中的内容和用户在他们的Python环境中安装时（根据你在setup.py中指定的内容）实际安装的内容是两回事；通常压缩包里的内容要比实际安装的多得多。
这让我立刻感到有些不对劲，并意识到一个分发版本可能有不止一种使用场景；我之前只关注过我参与过的那种情况，就是用easy_install或pip来安装一个库。然后我意识到，我正在开发的产品我对最终用户的理解还不够全面。
所以我的问题是：“除了在自己的Python环境中安装，还有哪些Python分发版本的使用场景？我这个分发版本还服务于谁，他们最关心什么？”
以下是一些我还没搞清楚的问题，这些问题与答案有关：
把所有在源代码管理（git）下的内容都包含在源分发中合理吗？在github盛行的今天，还有人会下载源分发来获取完整的项目源代码吗？还是说我直接发个链接到我的github仓库就行？把所有东西都包含进去会不会让分发版本变得庞大，下载时间变长，尤其是对那些只想安装的人来说？
我打算把文档托管在readthedocs.org上。把文档的HTML版本包含在源分发中有意义吗？
有没有人用
python setup.py test来在源分发上运行测试？如果有，他们是什么角色，处于什么情况？我不知道我是否应该花时间去实现这个，如果要实现，应该为谁去做。
1 个回答
有些东西你可能想放在源代码包里，但不一定要安装，比如：
- 这个软件包的许可证
- 测试套件
- 文档（可能还包括处理过的版本，比如HTML格式，除了源代码之外）
- 可能还有一些用来构建源代码包的额外脚本
通常情况下，这些内容可能占据了你在版本控制中管理的大部分，甚至全部，还有一些生成的文件。
这样做的主要原因是，即使这些文件可以在线获取或通过版本控制访问，大家也能确保他们手里的文档或测试版本和他们运行的代码是匹配的。
如果你只在网上提供最新版本的文档，那么对于那些因为某种原因需要使用旧版本的人来说，这些文档可能就没什么用。而版本控制中的测试套件可能和源代码包中的代码版本不兼容（比如，如果它测试的是之后添加的功能）。为了找到合适的文档或测试，他们就得在版本控制中翻找，寻找与源代码包对应的标签（前提是开发者有打标签）。把这些文件放在源代码包里就能避免这个问题。
至于那些想运行测试套件的人，我有一些Python模块被打包在不同的Linux发行版中，偶尔会收到关于测试失败的bug报告。当我遇到bug时，我也会使用其他人的模块的测试套件，看看外部代码在我的环境中是否按作者的预期工作。