Pipenv: 依赖关系无法解决。 回归?

创建于 2017-10-10  ·  14评论  ·  资料来源: pypa/pipenv

嘿,肯尼斯,这曾经奏效,所以我不知道发生了什么。

$ pipenv --version
pipenv, version 8.2.6

$ cat Pipfile
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]
django-cms = "*"
django = "*"

$ pipenv lock             
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django<1.11,==1.11.6,>=1.8
Tried: 1.1.3, 1.1.3, 1.1.4, 1.1.4, 1.2, 1.2, 1.2.1, 1.2.1, 1.2.2, 1.2.2, 1.2.3, 1.2.3, 1.2.4, 1.2.4, 1.2.5, 1.2.5, 1.2.6, 1.2.6, 1.2.7, 1.2.7, 1.3, 1.3, 1.3.1, 1.3.1, 1.3.2, 1.3.2, 1.3.3, 1.3.3, 1.3.4, 1.3.4, 1.3.5, 1.3.5, 1.3.6, 1.3.6, 1.3.7, 1.3.7, 1.4, 1.4, 1.4.1, 1.4.1, 1.4.2, 1.4.2, 1.4.3, 1.4.3, 1.4.4, 1.4.4, 1.4.5, 1.4.5, 1.4.6, 1.4.6, 1.4.7, 1.4.7, 1.4.8, 1.4.8, 1.4.9, 1.4.9, 1.4.10, 1.4.10, 1.4.11, 1.4.11, 1.4.12, 1.4.12, 1.4.13, 1.4.13, 1.4.14, 1.4.14, 1.4.15, 1.4.15, 1.4.16, 1.4.16, 1.4.17, 1.4.17, 1.4.18, 1.4.18, 1.4.19, 1.4.19, 1.4.20, 1.4.20, 1.4.21, 1.4.21, 1.4.22, 1.4.22, 1.5, 1.5, 1.5.1, 1.5.1, 1.5.2, 1.5.2, 1.5.2, 1.5.2, 1.5.3, 1.5.3, 1.5.4, 1.5.4, 1.5.5, 1.5.5, 1.5.6, 1.5.6, 1.5.7, 1.5.7, 1.5.8, 1.5.8, 1.5.8, 1.5.8, 1.5.9, 1.5.9, 1.5.10, 1.5.10, 1.5.11, 1.5.11, 1.5.12, 1.5.12, 1.5.12, 1.5.12, 1.6, 1.6, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.6.11, 1.6.11, 1.7, 1.7, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.7.11, 1.7.11, 1.8a1, 1.8a1, 1.8b1, 1.8b1, 1.8b2, 1.8b2, 1.8rc1, 1.8rc1, 1.8, 1.8, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.8.18, 1.8.18, 1.9a1, 1.9a1, 1.9b1, 1.9b1, 1.9rc1, 1.9rc1, 1.9rc2, 1.9rc2, 1.9, 1.9, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.10.8, 1.10.8, 1.11a1, 1.11a1, 1.11b1, 1.11b1, 1.11rc1, 1.11rc1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.5, 1.11.5, 1.11.6, 1.11.6, 1.11.6, 1.11.6, 2.0a1, 2.0a1

$ pipenv graph              
django-cms==3.4.4
  - Django [required: >=1.8,<1.11, installed: 1.11.6]
    - pytz [required: Any, installed: 2017.2]
  - django-classy-tags [required: >=0.7.2, installed: 0.8.0]
    - Django [required: >1.3, installed: 1.11.6]
      - pytz [required: Any, installed: 2017.2]
  - django-formtools [required: >=1.0, installed: 2.1]
    - Django [required: >=1.8, installed: 1.11.6]
      - pytz [required: Any, installed: 2017.2]
  - django-sekizai [required: >=0.7, installed: 0.10.0]
    - django-classy-tags [required: >=0.3.1, installed: 0.8.0]
      - Django [required: >1.3, installed: 1.11.6]
        - pytz [required: Any, installed: 2017.2]
  - django-treebeard [required: >=4.0.1, installed: 4.1.2]
    - Django [required: >=1.7, installed: 1.11.6]
      - pytz [required: Any, installed: 2017.2]
  - djangocms-admin-style [required: >=1.0, installed: 1.2.7]

因此,Django CMS要求> = 1.8,<1.11,但是pipenv试图匹配<1.11,** == 1.11.6 **,> = 1.8?

使用--skip-lock安装确实安装了1.11.6,这是最新的Django。

我希望可以根据CMS要求安装1.10版。

Dependency Resolution Type Discussion help wanted

最有用的评论

这个曾经修复过吗? 我仍然遇到相同的错误行为。
https://github.com/pypa/pipfile/issues/114

所有14条评论

看起来pipenv为当前回合候选人增加了严格的条件。

这意味着,如果在下一轮中,其他软件包要求的版本与当前候选者不匹配,则它将失败(像这样),而不是尝试寻找其他候选者。 这就是解析算法的工作原理:完全重新计算新约束,直到稳定为止。

我不确定是什么原因造成的。
我注意到要重现此内容,如果以前我仅使用pip-tools ,则必须清除缓存( --clear )。
我可以说这不是pip-tools错误,它与pip-tools的补丁没有直接关系(我尝试将它们全部删除,并且仍然会发生)。
我希望这会有所帮助。

好吧,找到了罪魁祸首:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values()包含固定的req_to_install本身,将其作为依赖项返回是错误的,并且如果后续程序包要求的版本不符合目前的候选人。 这样做是假设我们的第一个候选人必须是正确的候选人,否则就会失败。

@kennethreitz据我了解,那是做“深入的临时演员解决”。 我不确定我明白这到底是什么意思。 我准备继续为此刺中,但我需要一些信息以免走错方向。

我相信我也遇到了同样的问题:

$ pipenv --version
pipenv, version 8.2.7

$ pipenv install
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django==2.0a1,>=1.8,>=1.8.0
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6, 2.0a1

其中2.0a1显然是可用选项之一。

由于https://github.com/kennethreitz/pipenv/issues/786,我无法在任何较旧版本的pipenv中测试依赖项解析

同样的问题-它专门抱怨请求。

我认为这是与@vphilippon的评论有关的错误。 我不认为这与#909有关。

确切,与#909不相关。
就像我说的那样,我需要来自@maintainers之一的输入,以了解“深度额外解决”在这里的确切含义。 我有一个解决方法,但我想知道的更多信息是不要先破坏任何内容。

或者,我可以继续使用修复程序打开PR,并在那里进行讨论。 有空的时候我会看看。

@vphilippon因为这不是组织中的工作,而是Kenneth的个人@erinxocon和我自己。

不幸的是,这里要点的补丁被锁定在肯尼斯(Kenneth)头部的某个地方。 我认为我不了解或没有时间去看这里发生的事情。 如果您有时间整理您的想法,我可以尝试帮助您验证假设。 在此之前,在进行更改之前,我们必须轻描淡写。

@nateprewitt好吧,我会尽可能多地添加。 抓住椅子。

怎么了?

https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812中,我指出了错误的来源:在解决回合中选择的候选对象直接添加为候选对象自身的固定依赖关系,这是错误的(还有更多内容

https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268中,我找到了该引脚的来源:添加到返回值中的self.requirements.values()包括当前程序包的一个引脚。 换句话说, _prepare_file应该返回软件包的依赖关系(或“还要安装的其他InstallRequirements列表”),但是现在它包含固定的自身作为其依赖关系。

为了帮助说明为什么将包本身固定为自己的依赖关系确实是错误的,以下是依赖关系解析算法的工作原理:

  1. 获取initial_constraints_set ,即InstallRequirements的列表(例如: requests>=2.18 )。
  2. additional_constraintscandidate为空集。
  3. 选择一组尊重initial_constraints_setadditional_constraints并集的candidate (例如: requests==2.18.4
  4. 对于每个候选者,获取并合并所有候选者的依赖项集,如additional_constraints (例如: certifi>=2017.4.17
  5. 如果additional_constraints已更改,请清除candidate并返回3。
  6. 返回候选集,完成。

现在,让我们牢记上述内容。

要重现此问题,您需要以下Pipfile (因为发布了带有Django 1.11支持的`django-cms 3.4.5):

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]
django-cms = "==3.4.4"
django = "*"

现在pipenv lock --verbose --clear

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  django
  django-cms==3.4.4

Finding the best candidates:
  found candidate django==1.11.6 (constraint was <any>)
  found candidate django-cms==3.4.4 (constraint was ==3.4.4)

Finding secondary dependencies:
  django-cms==3.4.4 not in cache, need to check index
  django-cms==3.4.4         requires django-classy-tags>=0.7.2, django-cms==3.4.4, django-formtools>=1.0, django-sekizai>=0.7, django-treebeard>=4.0.1, Django<1.11,>=1.8, djangocms-admin-style>=1.0
  django==1.11.6 not in cache, need to check index
  django==1.11.6            requires django==1.11.6, pytz

New dependencies found in this round:
  adding [u'django', '<1.11,==1.11.6,>=1.8', '[]']
  adding [u'django-classy-tags', '>=0.7.2', '[]']
  adding [u'django-cms', '==3.4.4', '[]']
  adding [u'django-formtools', '>=1.0', '[]']
  adding [u'django-sekizai', '>=0.7', '[]']
  adding [u'django-treebeard', '>=4.0.1', '[]']
  adding [u'djangocms-admin-style', '>=1.0', '[]']
  adding [u'pytz', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  django<1.11,==1.11.6,>=1.8
  django-classy-tags>=0.7.2
  django-cms==3.4.4
  django-formtools>=1.0
  django-sekizai>=0.7
  django-treebeard>=4.0.1
  djangocms-admin-style>=1.0
  pytz

Finding the best candidates:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django<1.11,==1.11.6,>=1.8
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6
  • 在单个解析回合中,我们检测到必须安装django==*django-cms==3.4.4
  • 我们选择候选人: django==1.11.6django-cms==3.4.4
  • 我们得到了依赖关系(我将重点放在重要部分):

    • django-cms==3.4.4需要django<1.11,>=1.8

    • django需要django==1.11.6 (这是不正确的,django不需要自己!没有软件包需要自己!)

  • 我们将依赖说明符合并在一起:

    • 现在,我们需要django <1.11,==1.11.6,>=1.8 (您可以看到行进方向...)

  • 约束已更改,回到选择候选对象。
  • 尝试找到django的候选人,即<1.11,==1.11.6,>=1.8

    • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]

应该发生了什么(就像在pip-tools所做的那样,使用未修补的pip ,使用--rebuild清除缓存):

  • 在单个解析回合中,我们检测到必须安装django==*django-cms==3.4.4
  • 我们选择候选人: django==1.11.6django-cms==3.4.4
  • 我们得到了依赖关系(我将重点放在重要部分):

    • django-cms==3.4.4需要django<1.11,>=1.8

    • django需要pytz但不需要django==1.11.6

  • 我们将依赖说明符合并在一起:

    • 现在我们需要django <1.11,>=1.8 (好多了...)

  • 约束已更改,回到选择候选对象。
  • 尝试找到django的候选人,即<1.11,>=1.8

    • 选择一个新的django候选对象,可能是django==1.10.8

  • 计算依赖关系,继续前进并愉快地解决。

从这里做什么?

好了,从_prepare_file的退货中删除self.requirements.values()可以解决此问题,我可以确认。 不幸的是,我还没有到底为什么它被添加有想通。

也许肯尼思(Kenneth)想要对候选人本身返回一个InstallRequirement对象,对它执行一些操作后才能获得与“深度额外解决”相关的信息(我实际上是在这里展开)。 我可以尝试修补该修补程序,以将其他InstallRequirement对象保留在返回值中,但先取消固定。 我很确定不是故意的,即使是故意的,它也是坏的。

我认为就是这样。 ☕️

@vphilippon ,非常感谢您提供如此详细的细分! 这肯定为我清除了一切。

追溯到提交日志,它已添加到ae4591b2中,正如您所说的,尚不清楚为什么要添加它。 我认为下一步是将一个失败的测试用例和一个用于安装“深度依赖”的有效测试用例放在一起。 没有任何问题出现此问题,提交消息也无济于事,因此,我们此时仅是一种猜测。

查看代码,我认为这是在尝试解决像requests[security]这样的声明,该声明可能具有依赖项certifi[some-extra] ,这也需要解决。 至少这是我唯一想到的。 我敢打赌,Django宇宙中正在这样做,如果我们能找到一个让我们编写测试的示例。

所以! 如果有人想将这些测试放在一起,确保第一个测试失败并且“深度依赖”起作用,我们可以考虑删除self.requirements.values()声明。

@nateprewitt这是我认为可以描述您的意思的东西:
https://github.com/vphilippon/testdeepextra

但是,在pip-tools ,“ foo [a]取决于bar [b]”深度解析似乎已经可以
因此,该补丁可能不完全是那个补丁,因为我会假定它最初在pip-tools不起作用。 除非针对某些特定情况,否则我无法在此处进行测试。

无论如何,无论有没有补丁,我们仍然可以使用该存储库测试pipenv多余部分的解析行为(我没有时间立即做),看看它是否有效果,以及/或与pip-tools的输出进行比较。 至少我们有一个起点。

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sanic-plugins-framework==0.5.0.dev20171225,>=0.5.0.dev20171225
Tried: 0.2.0.dev20171102, 0.2.0.dev20171102, 0.3.0.dev20171102, 0.3.0.dev20171102, 0.3.1.dev20171102, 0.3.1.dev20171102, 0.3.2.dev20171102, 0.3.2.dev20171102, 0.3.3.dev20171102, 0.3.3.dev20171102, 0.4.0.dev20171103, 0.4.0.dev20171103, 0.4.1.dev20171103, 0.4.1.dev20171103, 0.4.2.dev20171106, 0.4.2.dev20171106, 0.4.4.dev20171107, 0.4.4.dev20171107, 0.4.5.dev20171113, 0.4.5.dev20171113, 0.5.0.dev20171225, 0.5.0.dev20171225, 0.5.2.dev20180201, 0.5.2.dev20180201
  1. 当软件包的版本等于'*'时出现此错误,但是当我将其更改为已知的版本(例如'== 0.1.2')时,它运行良好。
  2. 不幸的是,当我输入pipenv install sanic-plugins-framework==0.5.0.dev20171225 ,我收到了这个大错误消息。 也许以上所有版本都不大于'0.5.0.dev20171225'
  3. 我应该怎么做才能解决这个问题

pipenv lock —pre —clear

感谢您@Jasonsey分享你的位,并@techalchemy你的答案。
我在sanic-plugins-framework遇到了问题,并添加了--pre (_Allow pre-releases._标志)帮助我安装了软件包the

这个曾经修复过吗? 我仍然遇到相同的错误行为。
https://github.com/pypa/pipfile/issues/114

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

randName picture randName  ·  3评论

hynek picture hynek  ·  3评论

FooBarQuaxx picture FooBarQuaxx  ·  3评论

jeyraof picture jeyraof  ·  3评论

bgjelstrup picture bgjelstrup  ·  3评论