想象一个项目MyLibrary,它曾经有自己的requirements.txt文件,指定每个依赖项所需的所有版本......lib_a==0.1lib_b==0.11lib_c==0.1.1lib_d==0.1.2lib_e==0.1.8还有一个项目ChildProject恰好具有相同类型的设置,具有自己的requirements.txt文件和所有内容。ChildProject使用,MyLibrary因为它需要它具有的一些通用功能。这两个的问题在于,它ChildProject有一个也在 中指定的库MyLibrary,但版本不同,这会导致冲突并导致构建失败。我为解决这个问题所做的工作是删除依赖项MyLibrary并为每个库指定最小和最大版本,setup_requires在setup()方法中的属性中指定那些......setup( setup_requires=['pbr', 'pytest-runner'], install_requires=[ 'lib_a>=0,<1', 'lib_b>=0,<2', 'lib_c>=0,<3', 'lib_d>=0,<4', 'lib_e>=0,<5' ], pbr=True,)这就是我迷路的地方......我应该删除requirements.txt的MyLibrary,并使用全部留给版本儿童项目?如果是这样,我怎么知道ChildProject指定了所有需要的依赖项?如果我错过指定lib_ainChildProject怎么办?是否setup_requires会自动安装符合约束的最新版本或它是如何工作的?(我问这个是因为 AFAIK,install_requires只是指定了约束,但在项目中不包含任何库)。
1 回答

神不在的星期二
TA贡献1963条经验 获得超6个赞
管理 deps 版本的一般建议:
库dont't引脚版本(即要么
install_requires
没有版本可言,或松散的限制,即<4
)。这就是你已经拥有的应用程序可以做任何需要的事情。实际上,强烈建议将您的依赖项固定到某个确切的版本(蚂蚁更好 - 提供哈希,以保护自己免受伪造的库的影响)。原因 - 您不能保证 3rd-party 库遵循semver。这意味着
>2, <3
在您的系统中requirements.txt
可能会导致构建/部署中断,因为发布的 3rd 方库2.5
似乎与2.4
. 因此,您必须尽力避免通过在不同时间重新构建来破坏构建。换句话说,你的构建应该在 PyPI 状态下是幂等的。通常——您将版本固定到某个状态,测试您的应用程序并提交/保存/构建/无论您如何交付。一段时间后,您正在修改版本(即更新框架或解决安全补丁),更新 中的版本
requirements.txt
,使用新的 deps 状态测试您的应用程序,如果没有冲突/损坏的部分,则使用固定版本“冻结”该状态,和构建/部署/等。这种循环为您提供了偶尔更新您的需求以保持最新状态的空间,同时您的代码不会因为重新安装依赖项而被破坏。
如果您希望通过版本更轻松地进行 dep 管理,我建议您查看 pipenv
添加回答
举报
0/150
提交
取消