Python：一个存储库中有多个包还是每个存储库一个包？

Posted 2023-02-21

【中文标题】Python：一个存储库中有多个包还是每个存储库一个包？

【英文标题】：Python: Multiple packages in one repository or one package per repository?

【发布时间】：2019-06-13 10:12:02

【问题描述】：

我有一个大型 Python 3.7+ 项目，目前正在将其拆分为多个可以单独安装的包。我最初的想法是拥有一个包含多个包的 Git 存储库，每个包都有自己的 setup.py。然而，在对 Google 进行一些研究时，我发现有人建议每个包一个存储库：（例如，Python - setuptools - working on two dependent packages (in a single repo?)）。然而，没有人能很好地解释为什么他们更喜欢这种结构。

所以，我的问题如下：

在同一个 GitHub 存储库中拥有多个包（每个包都有自己的 setup.py）意味着什么？ 我会遇到这样的设置问题吗？ 常见的 Python 工具（文档生成器、pypi 打包等）是否与此类设置兼容？ 是否有充分的理由选择一种设置而不是另一种设置？ 请记住，这不是一个基于意见的问题。我想知道这两种方法是否存在任何技术问题或问题。

另外，我知道（如果我错了，请纠正我）setuptools 现在允许从 GitHub 存储库安装依赖项，即使 setup.py 的 GitHub URL 不在存储库的根目录下。

【问题讨论】：

单独包的优点：一些 Github 工具，比如 wiki 或问题，也可以分开，因此它们处理的信息将更易于管理。此外，如果用户只需要其中一个包，则他或她不需要下载其他包。

@AstrOne 对您在这里提出的想法非常感兴趣。我正在做一个项目，我们有两个独立的私有包，它们有自己的存储库，但其中一个包依赖于另一个包。这很快使测试变得有点像噩梦。我认为我们可以（a）推出一些好的 CI devops 基础设施，或者（b）将包放在同一个 repo 中并巩固测试基础。我目前偏爱 (b)，因为它似乎是最快的路径，而且我们还处于早期阶段，但非常想知道最佳实践是什么。

您好！我只是在想，如果包的相互依赖性使得将它们保存在同一个存储库中非常有益，以至于用户更愿意这样做，那么这可能是生态系统的一个问题。我的考虑是我希望来自不同作者的包通常是相互依赖的。因此，它们几乎不可能被放入同一个 repo 中（如果没有高度的协作，则不能）。因此，如果您遇到的问题仍然存在，最好向广大受众/PEP 定义人员提出这些问题？

【参考方案1】：

这里涵盖了一个方面 https://pip.readthedocs.io/en/stable/reference/pip_install/#vcs-support

特别是，如果 setup.py 不在根目录中，您必须在 pip install 命令中指定找到 setup.py 的子目录。

因此，如果您的存储库布局是：

pkg_dir/ setup.py # setup.py for package pkg some_module.py other_dir/ some_file some_other_file

您需要使用 pip install -e vcs+protocol://repo_url/#egg=pkg&subdirectory=pkg_dir。

【参考方案2】：

我自己也在研究同样的问题。 PyPa 文档推荐在“native”子目录中描述的布局：https://github.com/pypa/sample-namespace-packages

我发现下面描述的单个包结构非常有用，请参阅有关测试“已安装”版本的讨论。 https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure 我认为这可以扩展到多个包。当我了解更多时会发布。

【讨论】：

请举例说明链接背后的潜在用途

【参考方案3】：

“最佳”方法？这是一个见仁见智的问题，这不是 SO 的领域。但这里有几个创建单独包的理由：

包在功能上独立于您项目中的其他包。 也就是说，不会从它们导入并执行可能对其他开发人员有用的功能。如果此包执行的功能类似于 PyPI 中已有的包，则加分。 如果软件包具有稳定的 API 和清晰的文档，则可以加分。如果包是你为了便于维护从多个包中分解出来的不相关功能的薄抓包，但功能没有统一的原则，则会被扣分。 该软件包对于您的主项目是可选的，因此在某些情况下用户可以合理地选择跳过安装它。 也许一个包是“客户端”，另一个是“服务器”。或者该软件包可能提供特定于操作系统的功能。 请注意，像这样的包不在功能上独立于主项目，因此不符合前面的要点，但这仍然是一个很好的理由将其分开。

我同意@boriska 的观点，即“单包”项目结构是一种维护便利，非常值得努力。但不是（这只是我的观点，我会因为表达它而被否决），代价是公共包索引与大量从未单独安装的小包混淆。

【讨论】：

+1 表示“从不单独安装” - 这是一个非常好的观点，也是将几个小包折叠成一个小包的好方法