5

我正在为我正在编写的 Python 包开发一个发行版，以便可以将其发布在 PyPI 上。这是我第一次使用 distutils、setuptools、distribute、pip、setup.py 和所有这些，我正在努力学习曲线，它比我预期的要陡峭一些 :)

通过在 setup.py的参数中指定它们来将我的一些测试数据文件包含在 tarball 中时，我遇到了一些麻烦，data_files直到我在这里遇到另一篇将我指向该MANIFEST.in文件的帖子。就在那时，我突然想到，您在 tarball/zip 中包含的内容（使用 MANIFEST.in）以及在用户执行 easy_install 或其他任何操作时安装在用户的 Python 环境中的内容（基于您在 中指定的内容setup.py）是两个非常不同的东西; 一般来说，tarball 中的内容比实际安装的要多得多。

这立即引发了我的代码异味，并意识到发行版必须有多个用例；我一直专注于我真正参与的唯一一个，使用 easy_install 或 pip 安装库。然后我意识到我正在开发工作产品，而我对我正在开发的最终用户只有部分了解。

所以我的问题是：“除了将 Python 发行版安装在自己的 Python 环境中之外，还有哪些用例？我还为谁服务于这个发行版，他们最关心什么？”

以下是一些我尚未弄清楚的与答案有关的工作问题：

  • 在源代码分发中包含源代码控制 (git) 下的所有内容是否明智？在 github 时代，有没有人下载源代码分发来访问完整的项目源代码？或者我应该只发布一个指向我的 github 存储库的链接？不会包含所有内容会使发行版膨胀并使只想安装它的人花费更长的时间下载吗？

  • 我将在 readthedocs.org 上托管文档。在源代码分发中包含 HTML 版本的文档对我来说有意义吗？

  • 有没有人用来python setup.py test在源代码发行版上运行测试？如果是这样，他们扮演什么角色，他们处于什么情况？我不知道我是否应该费心去做这项工作，如果我这样做，该为谁工作。

4

1 回答 1

4

您可能希望在源代码分发中包含但可能不安装的一些内容包括：

  • 包的许可证
  • 一个测试套件
  • 文档（可能是经过处理的表单，如 HTML 以及源代码）
  • 可能用于构建源代码分发的任何其他脚本

通常这将是您在版本控制中管理的大部分或全部内容，可能还有一些生成的文件。

当这些文件在线或通过版本控制可用时，您这样做的主要原因是让人们知道他们拥有与他们正在运行的代码相匹配的文档或测试版本。

如果您只在线托管最新版本的文档，那么它们可能对出于某种原因必须使用旧版本的人没有用处。并且版本控制中尖端的测试套件可能与源代码分发中的代码版本不兼容（例如，如果它测试从那时起添加的功能）。为了获得正确版本的文档或测试，他们需要梳理版本控制，寻找与源代码分发相对应的标签（假设开发人员打扰标记树）。让源代码分发中的文件可用可以避免这个问题。

至于想要运行测试套件的人，我有许多 Python 模块打包在各种 Linux 发行版中，偶尔会收到与他们环境中的测试失败相关的错误报告。当我遇到错误并想检查外部代码在我的环境中是否按照作者期望的方式运行时，我也使用了其他人模块的测试套件。

于 2013-01-21T11:35:08.267 回答