如何将另一个tox项目文件夹指定为tox项目的依赖项

我们有一个启用 tox的项目(让我们称之为“主”项目),它依赖于另一个tox项目(让我们称之为“库”项目) – 所有项目都集成在一个存储库中,因为它是一个大型总体项目的一部分.

项目如何为普通用户工作

对于作为最终用户的常规安装,您只需先从存储库或任何来源安装“library”然后再“main”,然后运行它.

我们的问题是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获取“库”.但是,该项目尚未发布(因此不在点)因此它将无法工作 – 即使lib就在同一个仓库中.

结果：它不起作用.

解决方法1：我们可以设置自己的包索引/要求用户这样做.但是,要求每个为项目做出贡献的人都使用DevPI或类似工具来运行单元测试似乎不是一个好主意,因此我们需要集中进行.

但是如果我们在某个中心位置提供了包索引或者为“库”提供了一个pip包,那么人们就无法通过参与他们自己创建的“库”的修改版本轻松地运行“main”测试：

毕竟“库”在同一个存储库中,所以人们不妨在某个时候修改它.

在“主”项目文件夹中键入“tox”将不会轻易获取当前相邻的“库”版本,但只有预先打包的在线内容并不完全直观.

解决方法2：我们尝试了sitepackages = True并在系统中安装“library” – 但是,sitepackages = True导致了我们显着的麻烦,一般来说这似乎不是一个好主意.
>期望的行为：我们希望tox在相同的总体存储库中使用该文件夹中的“库”的本地版本,人们通常会在一个存储库中获取：

该版本可能更新,甚至可能在本地修改,因此这显然是开发用户想要使用的版本.它存在,现在不能说关于pip包.

为什么我们仍然希望使用子项目(“主”,“库”……)而不仅仅是一个项目的总体存储库？

我们开发了一个多守护进程的大型项目,其中包含许多用于各种目的的守护进程,在一些库中共享代码以形成大学课程管理系统(处理论坛,课程管理,可以提交事物,附加代码版本系统用于学生项目等等.).

可以只使用守护进程的一个子集,因此它们是单独的项目是有意义的,但它们仍然足够连接,大多数人都希望拥有大部分 – 因此所有这些都在一个存储库中.

库本身也适用于完全不同的项目,但它通常用于我们的开头 – 所以它就是填充到存储库中的地方.这意味着它总是在给定的相对路径中,但它有单独的tox.ini和单元测试.

TL; DR /摘要

那么我们如何让tox在另一个toxable项目文件夹中寻找特定的依赖项而不是在安装项目时只是pip？

当然“main”的常规setup.py安装过程不应该乱用tox或搜索本地磁盘：它应该检查一个特定的相对路径,然后放弃,如果那个不存在(并回退)小便或其他).

如果相对路径可以以某种方式存储在tox.ini中,那么最好.

或者这只是一个非常糟糕的主意？我们是否应该以不同的方式解决这个问题,以使我们的“主要”项目能够轻松地使用本地存储库中存在的最新本地开发版“库”？

您可以在主项目中使用pip的–editable选项,如下所示：

deps =
    --editable=file:///{toxinidir}/../library
    -r{toxinidir}/requirements.txt

附：不要使用这种风格：-e file：/// {toxinidir} /../library,因为tox将整个字符串作为参数传递给错误foramt中的argparse.