我们有一个启用了 tox 的项目(让我们称之为“主”项目),它依赖于另一个 tox 项目(让我们称之为“库”项目)-全部统一在一个仓库中,因为它们都是一个大型综合项目的一部分。
对于普通用户的项目工作方式
对于普通用户的常规安装,您只需从仓库或其他来源安装“库”项目,然后再安装“主”项目,然后运行它。
我们使用 tox 遇到的问题
然而,作为开发者,情况就不同了,因为“tox”应该工作,并且您可能希望同时拥有多个版本。
您通常会检出大型综合仓库,然后文件系统布局如下:
overarchingproject/main/
overarchingproject/main/src/
overarchingproject/main/tox.ini
overarchingproject/main/setup.py
...
overarchingproject/library/
overarchingproject/library/src/
overarchingproject/library/tox.ini
overarchingproject/library/setup.py
...
现在,如果我进入main/文件夹并输入“tox”,会发生以下情况:
当前行为: 它将尝试使用对“library”的依赖来构建“main”项目 - 这显然会尝试从pip获取“library”。然而,该项目尚未发布(因此不在pip上),所以它无法正常工作 - 即使该库就在同一个仓库中。
结果:它不起作用。
解决方法 1: 我们可以设置自己的软件包索引或要求用户这样做。但是,要求每个为项目做贡献的人使用DevPI或类似工具来运行单元测试似乎不是一个好主意,因此我们需要集中处理。
但是,如果我们在某个中心位置提供软件包索引或“library”的pip软件包,人们将不能轻松地使用他们自己创建的“library”的修改版本来运行“main”的测试:
"library"毕竟在同一个仓库中,所以人们可能会在某个时候进行修改。
在“main”项目文件夹中键入“tox”将不会轻松地检测到相邻的“library”版本,而只有一个在线预打包的东西,这并不是很直观。
解决方法 2: 我们尝试了sitepackages=True并在系统中安装“library” - 然而,sitepackages=True给我们带来了相当多的麻烦,并且它在一般情况下似乎不是一个好主意。
期望的行为: 我们想要tox使用文件夹中的本地版本“library”,该文件夹与跨越整个仓库的项目在同一个层次结构下,用户通常会获得它们:
这个版本可能是更新的甚至是本地修改的,因此这显然是开发人员想要使用的版本。 它确实存在,而现在不能说pip软件包也存在。
为什么我们需要跨越多个子项目(“main”,“library”等)的总体仓库,而不仅仅是一个单一项目?
我们开发了一个多守护进程的大型项目,其中包含许多用于各种目的的守护进程,在某些库中共享代码以形成大学课程管理系统(涉及论坛、带有提交功能的课程管理、适用于学生项目的附加代码版本控制系统等)。
可以只使用一部分守护进程,因此将它们分开成不同的项目是有意义的,但它们仍然足够相互关联,以至于大多数人都希望拥有它们中的大部分 - 因此所有它们都在一个存储库中。
该库本身也适用于完全不同的项目,但通常用于我们的项目 - 因此它被塞到了存储库中。 因此,这意味着它始终在给定的相对路径中存在,但它有自己的tox.ini和单元测试。
TL;DR / 摘要
那么我们如何使tox在安装项目时查找另一个可toxable的项目文件夹中的特定依赖项,而