我们有一个启用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”,就会发生这种情况:
当前行为:它将尝试构建依赖于“库”的“主”项目 - 这显然会导致尝试从 pip 获取“库”。但是,该项目尚未发布(因此不在 pip 上),因此它无法工作 - 即使该库就在同一个 repo 中。
结果:它不起作用。
解决方法 1:我们可以设置自己的包索引/要求用户这样做。然而,要求每个为项目做出贡献的人都使用 DevPI 或类似的工具来运行单元测试似乎不是一个好主意,所以我们需要集中进行。
但是,如果我们在某个中心位置提供一个包索引或为“库”提供一个 pip 包,那么人们无法在涉及他们自己创建的“库”的修改版本的情况下轻松运行“主”测试:
毕竟“库”在同一个存储库中,所以人们不妨在某个时候修改它。
在“主”项目文件夹中键入“tox”将不会轻易地适应当前相邻的“库”版本,但只有预先打包的在线内容并不完全直观。
解决方法 2:我们尝试了 sitepackages=True 并在系统中安装“库” - 但是,sitepackages=True 给我们带来了很多麻烦,而且总的来说这似乎不是一个好主意。
期望的行为:我们希望 tox 在同一个总体存储库中使用该文件夹中“库”的本地版本,人们通常会得到一件事:
该版本可能更新,甚至本地修改,所以这显然是开发用户想要使用的。它存在,目前还不能说 pip 包。
为什么我们无论如何都想要带有子项目(“main”,“library”,...)的总体存储库,而不仅仅是一个项目?
我们开发了一个多守护进程的大型项目,其中包含许多用于各种目的的守护进程,在一些库中共享代码以形成一个大学课程管理系统(处理论坛,可以提交东西的课程管理,为学生项目附加的代码版本控制系统ETC。)。
可以只使用守护程序的一个子集,因此它们是独立的项目是有道理的,但它们仍然连接得足够多,以至于大多数人都希望拥有其中的大部分——因此它们都在一个存储库中。
该库本身也适用于完全不同的项目,但它通常用于我们的项目 - 所以这就是它被塞进存储库的地方。所以这意味着它总是在给定的相对路径中,但它有单独的 tox.ini 和单元测试。
TL;DR / 摘要
那么我们如何才能让 tox 在另一个可毒项目文件夹中查找特定的依赖项,而不是在安装项目时只使用 pip 呢?
当然,“main”的常规 setup.py 安装过程不应该乱用 tox 或搜索本地磁盘:它应该只检查一个特定的相对路径,然后如果那个不存在就放弃(并回退点子或其他)。
所以最好是相对路径可以以某种方式存储在 tox.ini 中。
或者这只是一个非常糟糕的主意?我们是否应该以不同的方式解决这个问题,以使我们的“主”项目易于使用本地存储库中存在的“库”的最新本地开发版本来毒化?