Python入口点因依赖性冲突而失败

时间:2018-10-25 06:22:38

标签: python

我在一个项目中工作,其中两个依赖项需要冲突的依赖项。特别是,该项目需要eli5==0.8tabulate>=0.7.7invocations==1.4.0tabulate==0.7.5

我仍然可以安装项目,导入模块并运行代码,但是当我尝试通过setup.py创建入口点并运行它时,遇到以下失败:

Traceback (most recent call last):
  File "/Users/user/.pyenv/versions/3.6.6/envs/repro/lib/python3.6/site-packages/pkg_resources/__init__.py", line 574, in _build_master
    ws.require(__requires__)
  File "/Users/user/.pyenv/versions/3.6.6/envs/repro/lib/python3.6/site-packages/pkg_resources/__init__.py", line 892, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/Users/user/.pyenv/versions/3.6.6/envs/repro/lib/python3.6/site-packages/pkg_resources/__init__.py", line 783, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (tabulate 0.8.2 (/Users/user/.pyenv/versions/3.6.6/envs/repro/lib/python3.6/site-packages), Requirement.parse('tabulate==0.7.5'), {'invocations'})

即使我尝试将tabulate的版本直接固定在我的setup.py中,也会遇到相同的失败。

如何解决这种情况?

作为附加信息。我使用的是Python 3.6.6,下面的最小python模块和setup.py可用于重现此问题。

a_script.py

def cli():
    print('Hello world')

if __name__ == '__main__':
    cli()

setup.py

from setuptools import setup

setup(
    name='repro',
    version='0.1',
    py_modules=['a_script'],
    install_requires=[
        'eli5==0.8',
        'invocations==1.4.0',
        # 'tabulate==0.8.2'
    ],
    entry_points='''
        [console_scripts]
        repro=a_script:cli
    ''',
)

2 个答案:

答案 0 :(得分:1)

欢迎来到依赖世界!

我不知道有解决此问题的干净方法。一些简单解决方法的提示:

  • 您能否找到满足较新要求的较旧依赖关系的更高版本(可能称为开发或不稳定)?如果是,则可以尝试使其通过您自己项目的集成测试(是否通过了您所有的名义用例)。
  • 您能找到满足您自己要求的较新版本依赖项的旧版本吗?如果是,则应测试在所有名义用例中是否都有效

如果以上方法均无效,则必须为其中一个有冲突的项目构建自定义版本(假设至少有一个是开源的)。理想情况下,您应该克隆最旧的版本(此处为invocation,将其版本设置为local version identifier(此处为1.4.0 + tab0-7),并更改其自身的要求以接受tabulate>=0.7.7 。然后使用该特殊版本,并再次全面测试您的所有用例均已通过。

如果修改后的项目的所有测试仍然通过,则可以尝试建议其维护者更改其版本要求以用于将来的发行版,例如,根据当前的开发树提出补丁/请求请求。

答案 1 :(得分:0)

我最近通过使用使用METADATA和GNU补丁制作的统一差异来对软件包的git diff文件进行补丁来解决这种情况。

如果您尝试部署应用程序,这是一个有效的解决方案,但是如果您正在编写库,那么唯一有效的解决方案是打扰维护者,并告诉他们放松约束,或者消除对他们工作的依赖