想象一下,一个项目MyLibrary
曾经有自己的requirements.txt
文件,指定每个依赖项所需的所有版本。。。你知道吗
lib_a==0.1
lib_b==0.11
lib_c==0.1.1
lib_d==0.1.2
lib_e==0.1.8
一个项目ChildProject
恰好有相同的设置,有自己的requirements.txt
文件和所有东西。你知道吗
ChildProject
使用MyLibrary
,因为它需要一些通用的功能。这两个的问题是ChildProject
有一个库,这个库也是在MyLibrary
中指定的,但是它的版本不同,这会导致冲突并导致构建失败。你知道吗
我所做的是删除MyLibrary
中的依赖项,并为每个库指定最小和最大版本,在setup()
方法的setup_requires
属性中指定这些版本。。。你知道吗
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,
)
这就是我迷路的地方。。。你知道吗
我是否应该删除MyLibrary
中的requirements.txt
,并将所有版本控制留给使用的子项目?你知道吗
如果是这样,我如何知道ChildProject
正在指定所需的所有依赖项?如果我没有在ChildProject
中指定lib_a
,该怎么办?你知道吗
是否自动安装了符合setup_requires
约束的最新版本,或者它是如何工作的?(我这样问是因为AFAIK,install_requires
只是指定了约束,但在项目中不包括任何库)。你知道吗
管理deps版本的一般建议:
install_requires
没有版本,或者限制宽松,即<4
)。你已经有了应用程序可以执行任何需要的操作。实际上,强烈建议您将依赖项固定到某个精确的版本(最好是提供hash,以避免伪造lib)。原因-您不能保证第三方库遵循semver。这意味着在您的
requirements.txt
中有>2, <3
可能会导致构建/部署中断,因为第三方lib发布了2.5
,它似乎与2.4
向后不兼容。因此,您必须尽最大努力避免破坏构建,只需在不同的时间重新构建即可。换句话说,您的构建应该在PyPI状态上是幂等的。你知道吗一般来说,您可以将版本固定到某个状态,测试应用程序并提交/保存/构建/以您交付的方式交付。一段时间后,你正在修改版本(即更新框架或地址安全补丁),更新
requirements.txt
中的版本,用新的deps状态测试你的应用程序,如果没有冲突/损坏的部分,你用固定的版本“冻结”该状态,这种循环为您提供了空间,可以偶尔更新您的需求以保持最新,同时您拥有的代码不会因为重新安装依赖项而被破坏。如果您希望通过版本实现更简单的dep管理,我建议您看看^{}
相关问题 更多 >
编程相关推荐