发表文章

[Python] pipenv ipython 包的需求解析失败 pipenv requirement resolution failure for the ipython package[pipenv]

jc159 2017-10-9 96

我认为你是切断了分辨率算法在 pipenv/patched/piptools/resolver.py 太快。 使我产生这种信念的三项意见是:

(1) 在干净的空 python27 pipenv 中, 键入 pipenv install ipython 成功安装 ipython, 但无法创建 Pipfile.lock , 但出现以下错误信息:

RuntimeError: No stable configuration of concrete packages could be found for the given constraints after 16 rounds of resolving.
This is likely a bug.

(2) 在新的空 python27 pipenv 中, 键入 pipenv install appnope backports.shutil-get-terminal-size decorator enum34 ipython-genutils pathlib2 pexpect pickleshare prompt-toolkit ptyprocess pygments scandir simplegeneric six traitlets wcwidth ipython 成功, 在安装和创建过程中 Pipfile.lock 。 我在这里使用的软件包的神奇列表只是步骤 (1) 告诉我有必要安装 ipython 。 这表明问题在于解决方法, 而不是这组特定的软件包的相互依赖性。

(3) 确实, 重新运行实验 (1), 但在手动更改 pipenv/patched/piptools/resolver.py 以允许它有额外的100轮分辨率之后, 在安装 ipython 和创建 Pipfile.lock 时都成功。

原文:

I think that you are cutting off the resolution algorithm in pipenv/patched/piptools/resolver.py too soon. The three observations that lead me to this belief are:

(1) In a clean empty python27 pipenv, typing pipenv install ipython succeeds in installing ipython but fails to create Pipfile.lock with the following error message:

RuntimeError: No stable configuration of concrete packages could be found for the given constraints after 16 rounds of resolving.
This is likely a bug.

(2) In a new empty python27 pipenv, typing pipenv install appnope backports.shutil-get-terminal-size decorator enum34 ipython-genutils pathlib2 pexpect pickleshare prompt-toolkit ptyprocess pygments scandir simplegeneric six traitlets wcwidth ipython succeeds, in both the installation and in the creation of Pipfile.lock. The magic list of packages I used here was just the packages that step (1) told me were necessary to install for ipython. This suggests that the problem is with the resolution method, not the interdependencies of this particular set of packages.

(3) Indeed, rerunning experiment (1), but after manually changing pipenv/patched/piptools/resolver.py so as to allow it an extra 100 rounds of resolution, succeeds in both the installation of ipython and in the creation of Pipfile.lock.

相关推荐
最新评论 (17)
vphilippon 2017-10-9
1

我无法重现这个在10回合内解决 ipython 依赖项 (需要 4) 是没有问题的。
您能否给出一个 --verbose 输出来查看解决过程中发生的事情?
我已经看到了一些问题与稳定的冲突解决程序, 所以让我们来看看这个。

原文:

I'm unable to reproduce this. I have no trouble resolving ipython dependencies within 10 rounds (it takes 4).
Could you give a --verbose output to see what's going on during the resolving?
I've seen some issue with the stabilisation of the resolver, so let's see this.

jc159 2017-10-9
2

不幸的是, --verbose 标志似乎没有在创建的部分中创建任何更多的输入 (在标准输出或 stderr 上)。 不过, 这里是您的阅读输出: pipenv.verbose.stdout.txt

如果这在调试中很有用, 则是在 Pipfile.lock 步骤 (2) 中生成的, 因为这应该是有关代码所查看的怪异类型的图形的一些信息 (以及有关我的计算机设置的一些信息): Pipfile.lock.txt

顺便说一下, 当我增加了解析器圆极限时, 我注意到冲突解决程序代码中有相当数量的日志记录语句。 但是, 我无法计算出如何运行代码, 以便这些日志记录语句处于活动状态。 如果您能告诉我, 我很乐意生成这些日志并将它们追加到此处。

谢谢!

原文:

Unfortunately the --verbose flag does not seem to create any more input (on stdout or stderr) in the part where Pipfile.lock is being created. Nonetheless, here is the output for your perusal: pipenv.verbose.stdout.txt

In case this is useful in debugging it, here is the Pipfile.lock that was produced in step (2), as that should some information about what weird kind of graph the code is looking at (as well as some info about my computer's setup): Pipfile.lock.txt

Incidentally, when I increased the resolver round limit I noticed that the resolver code has a fair number of logging statements in it. However, I was not able to figure out how to run the code so that those logging statements are active. If you can tell me that, I'd be happy to generate those logs and append them here.

Thank you!

vphilippon 2017-10-9
3

我的错, 实际上我需要你运行 pipenv lock --verbose (在那里你有一个 Pipfile specyfing 只 ipython 当然)。
"详细程度" 在 lock 运行时没有应用 install , 这是我的错误。

原文:

My bad, I'd actually need you to run pipenv lock --verbose (where you have a Pipfile specyfing only ipython of course).
The "verbosity" is no applied on the lock part when running install, that was my mistake.

jc159 2017-10-9
4

谢谢你的小费! 实际上, 这似乎更有用: pipenv.lock.verbose.stdout.txt

原文:

Thanks for the tip! Indeed this seems much more useful: pipenv.lock.verbose.stdout.txt

vphilippon 2017-10-9
5

这与#792非常相似。
这里肯定有一个 bug:
(我对 "查找从属依赖项" 行进行了排序以进行比较)

15轮:

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was ==0.1.0)
  found candidate backports.shutil-get-terminal-size==1.0.0 (constraint was <any>)
  found candidate decorator==4.1.2 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was <any>)
  found candidate ipython==5.5.0 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate pathlib2==2.3.0 (constraint was ==2.3.0)
  found candidate pexpect==4.2.1 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.4,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.6 (constraint was ==1.6)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  appnope==0.1.0            requires -
  backports.shutil-get-terminal-size==1.0.0 requires -
  decorator==4.1.2          requires -
  enum34==1.1.6             requires -
  ipython-genutils==0.2.0   requires -
  ipython==5.5.0            requires appnope; sys_platform == "darwin", backports.shutil-get-terminal-size; python_version == "2.7", decorator, pathlib2; python_version == "2.7" or python_version == "3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.4, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2
  pathlib2==2.3.0           requires scandir; python_version < "3.5", six
  pexpect==4.2.1            requires ptyprocess>=0.5
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  ptyprocess==0.5.2         requires -
  pygments==2.2.0           requires -
  scandir==1.6              requires -
  simplegeneric==0.8.1      requires -
  six==1.11.0               requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  wcwidth==0.1.7            requires -

16轮:

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was ==0.1.0)
  found candidate backports.shutil-get-terminal-size==1.0.0 (constraint was ==1.0.0)
  found candidate decorator==4.1.2 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was ==1.1.6)
  found candidate ipython==5.5.0 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate pathlib2==2.3.0 (constraint was ==2.3.0)
  found candidate pexpect==4.2.1 (constraint was ==4.2.1)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.4,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.6 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  appnope==0.1.0            requires -
  backports.shutil-get-terminal-size==1.0.0 requires -
  decorator==4.1.2          requires -
  enum34==1.1.6             requires -
  ipython-genutils==0.2.0   requires -
  ipython==5.5.0            requires appnope; sys_platform == "darwin", backports.shutil-get-terminal-size; python_version == "2.7", decorator, pathlib2; python_version == "2.7" or python_version == "3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.4, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2
  pathlib2==2.3.0           requires scandir; python_version < "3.5", six
  pexpect==4.2.1            requires ptyprocess>=0.5
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  ptyprocess==0.5.2         requires -
  pygments==2.2.0           requires -
  scandir==1.6              requires -
  simplegeneric==0.8.1      requires -
  six==1.11.0               requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  wcwidth==0.1.7            requires -

没有候选项更改, 没有依赖项更改, 但约束被检测为更改。检测约束更改时出现 bug。

我现在可以出于某种原因复制。我将尝试找出差异在哪里, 当它重现。

原文:

This is pretty similar to #792.
There's definitely a bug here:
(I sorted the "Finding secondary dependencies" lines for comparision)

Round 15:

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was ==0.1.0)
  found candidate backports.shutil-get-terminal-size==1.0.0 (constraint was <any>)
  found candidate decorator==4.1.2 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was <any>)
  found candidate ipython==5.5.0 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate pathlib2==2.3.0 (constraint was ==2.3.0)
  found candidate pexpect==4.2.1 (constraint was <any>)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.4,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.6 (constraint was ==1.6)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  appnope==0.1.0            requires -
  backports.shutil-get-terminal-size==1.0.0 requires -
  decorator==4.1.2          requires -
  enum34==1.1.6             requires -
  ipython-genutils==0.2.0   requires -
  ipython==5.5.0            requires appnope; sys_platform == "darwin", backports.shutil-get-terminal-size; python_version == "2.7", decorator, pathlib2; python_version == "2.7" or python_version == "3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.4, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2
  pathlib2==2.3.0           requires scandir; python_version < "3.5", six
  pexpect==4.2.1            requires ptyprocess>=0.5
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  ptyprocess==0.5.2         requires -
  pygments==2.2.0           requires -
  scandir==1.6              requires -
  simplegeneric==0.8.1      requires -
  six==1.11.0               requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  wcwidth==0.1.7            requires -

Round 16:

Finding the best candidates:
  found candidate appnope==0.1.0 (constraint was ==0.1.0)
  found candidate backports.shutil-get-terminal-size==1.0.0 (constraint was ==1.0.0)
  found candidate decorator==4.1.2 (constraint was <any>)
  found candidate enum34==1.1.6 (constraint was ==1.1.6)
  found candidate ipython==5.5.0 (constraint was <any>)
  found candidate ipython-genutils==0.2.0 (constraint was <any>)
  found candidate pathlib2==2.3.0 (constraint was ==2.3.0)
  found candidate pexpect==4.2.1 (constraint was ==4.2.1)
  found candidate pickleshare==0.7.4 (constraint was <any>)
  found candidate prompt-toolkit==1.0.15 (constraint was >=1.0.4,<2.0.0)
  found candidate ptyprocess==0.5.2 (constraint was >=0.5)
  found candidate pygments==2.2.0 (constraint was <any>)
  found candidate scandir==1.6 (constraint was <any>)
  found candidate simplegeneric==0.8.1 (constraint was >0.8)
  found candidate six==1.11.0 (constraint was >=1.9.0)
  found candidate traitlets==4.3.2 (constraint was >=4.2)
  found candidate wcwidth==0.1.7 (constraint was <any>)

Finding secondary dependencies:
  appnope==0.1.0            requires -
  backports.shutil-get-terminal-size==1.0.0 requires -
  decorator==4.1.2          requires -
  enum34==1.1.6             requires -
  ipython-genutils==0.2.0   requires -
  ipython==5.5.0            requires appnope; sys_platform == "darwin", backports.shutil-get-terminal-size; python_version == "2.7", decorator, pathlib2; python_version == "2.7" or python_version == "3.3", pexpect; sys_platform != "win32", pickleshare, prompt-toolkit<2.0.0,>=1.0.4, pygments, setuptools>=18.5, simplegeneric>0.8, traitlets>=4.2
  pathlib2==2.3.0           requires scandir; python_version < "3.5", six
  pexpect==4.2.1            requires ptyprocess>=0.5
  pickleshare==0.7.4        requires pathlib2; python_version in "2.6 2.7 3.2 3.3"
  prompt-toolkit==1.0.15    requires six>=1.9.0, wcwidth
  ptyprocess==0.5.2         requires -
  pygments==2.2.0           requires -
  scandir==1.6              requires -
  simplegeneric==0.8.1      requires -
  six==1.11.0               requires -
  traitlets==4.3.2          requires decorator, enum34; python_version == "2.7", ipython-genutils, six
  wcwidth==0.1.7            requires -

No candidate change, no dependencies change, yet the constraints are detected as changing. There's a bug in detecting the constraint changes.

I'm now able to reproduce for some reason. I'll try to spot where the diff is failing while it reproduces.

vphilippon 2017-10-9
6

我在 pip-tools 的修补版本中找到了一些东西。
Resolver. _iter_dependencies 中:

        elif ireq.markers:
            for dependency in self.repository.get_dependencies(ireq):
                yield dependency
        elif ireq.extras:
            for dependency in self.repository.get_dependencies(ireq):
                yield dependency
            return

这些调用 self.repository.get_dependencies(ireq)某个时候返回固定的依赖项对象 (如 enum34==1.1.6 ), 有时一个类似的对象 (包括标记), 有时没有 (和空集) 为 "相同 ireq " 之间的回合。

这将导致一些 "假的变化", 可能永远不会稳定, 如上述。

正如我所说的 "相同的 ireq ", 它不完全相同, 因为某些时候潜在的必需有一个标记, 有时没有。

注释此修补程序解决了我的问题。

@kennethreitz问: 这个补丁的目标到底是什么?

原文:

I found something in the patched version of pip-tools here.
In Resolver. _iter_dependencies:

        elif ireq.markers:
            for dependency in self.repository.get_dependencies(ireq):
                yield dependency
        elif ireq.extras:
            for dependency in self.repository.get_dependencies(ireq):
                yield dependency
            return

these call to self.repository.get_dependencies(ireq) will sometime return a dependency object pinned (like enum34==1.1.6), sometime a similar object including markers, and sometime nothing (and empty set) for the "same ireq" between rounds.

That will cause some "fake variation", potentially never stabilising, like above.

As I say "same ireq", it's not quite the same, as sometime the underlying req has a marker, and sometime not.

Commenting out this patch fixes the issue on my side.

@kennethreitz Question for you: what was the goal of this patch exactly?

sobolevn 2017-10-9
7

我也一样它实际上困扰我相当困难!

我的 Pipfile :

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

[requires]
python_version = '3.6'

[dev-packages]

"django-debug-toolbar" = "*"
"pep8-naming" = "*"
"flake8-builtins" = "==0.2"
"flake8-commas" = "==0.4.3"
"flake8-quotes" = "==0.9.0"
"flake8-blind-except" = "*"
"flake8-bugbear" = "*"
"flake8-comprehensions" = "*"
"flake8-pep3101" = "*"
pytest = "==3.0.7"
"pytest-flake8" = "==0.8.1"
"pytest-isort" = "==0.1.0"
"pytest-django" = "*"
"pytest-cov" = "*"
gitlint = "==0.8.2"
"pre-commit" = "*"
xenon = "*"
radon = "*"

[packages]

django = "<1.12"
"django-split-settings" = "*"
"django-axes" = "*"
"psycopg2" = "*"
gunicorn = "*"
unipath = "*"
"python-decouple" = "*"

解决方法:

  1. pipenv install -d
  2. pip install ipython
原文:

The same for me. It actually bothers me quite hard!

My Pipfile:

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

[requires]
python_version = '3.6'

[dev-packages]

"django-debug-toolbar" = "*"
"pep8-naming" = "*"
"flake8-builtins" = "==0.2"
"flake8-commas" = "==0.4.3"
"flake8-quotes" = "==0.9.0"
"flake8-blind-except" = "*"
"flake8-bugbear" = "*"
"flake8-comprehensions" = "*"
"flake8-pep3101" = "*"
pytest = "==3.0.7"
"pytest-flake8" = "==0.8.1"
"pytest-isort" = "==0.1.0"
"pytest-django" = "*"
"pytest-cov" = "*"
gitlint = "==0.8.2"
"pre-commit" = "*"
xenon = "*"
radon = "*"

[packages]

django = "<1.12"
"django-split-settings" = "*"
"django-axes" = "*"
"psycopg2" = "*"
gunicorn = "*"
unipath = "*"
"python-decouple" = "*"

A workaround:

  1. pipenv install -d
  2. pip install ipython
kennethreitz 2017-10-9
8

@vphilippon使 pip 工具解决额外的制造商

原文:

@vphilippon making pip-tools resolve extras makers

kennethreitz 2017-10-9
9

@jc159准确了解您需要的轮数。我们可能需要我们的默认。

原文:

@jc159 find out exactly how many rounds you need. we may need to up our default.

kennethreitz 2017-10-9
10

此修补程序允许 pip 工具在最终结果中具有 "508 说明符", 这对我们和用户都非常有用。事实上, 这是很重要的。但是, 它需要更多的回合, 这就是为什么我们增加了默认值。

这听起来像, 在这种情况下, 我们可能需要进一步增加它。

原文:

this patch allows pip-tools to have "508 specifiers" in it's final results, which are incredibly useful for us, and our users. It's essential, in fact. It does require more rounds, however, which is why we upped the default.

It sounds like, in this case, we may need to increase it further.

vphilippon 2017-10-9
11

@kennethreitz增加默认的轮数将不会解决真正的问题: 在约束中有 "随机" 的变化, 而它们应该是稳定的。所需的轮数将取决于您在这里的 "运气"。它至多可以减少永远不稳定的风险。
在不更改任何东西的情况下, 每次清除我的缓存时, 我都已成功地解决了 ipython 3、4、7回合中的依赖性, 有时在超过16个回合中失败。那是不好的。

我100% 确信, 在调试之后, 一行接一个地, 这里有一个 bug。所需的轮数应该是稳定的, 而不是在尝试之间进行更改。

此外, 即使在此处解决了附加和标记, 也可以在 _group_constraint 节中删除其中的一半。没有标记组合完成, 这意味着唯一的标记, 将获得通过将是一个在第一 ireq 的组合。

原文:

@kennethreitz Upping the default number of round will not fix the real issue here: There are "random" changes in the constraints while they should be stable. The number of round required will depend on your "luck" here. It will at best reduce the risk of never stabilising.
Without changing a thing, clearing my cache every time, I've managed to resolve the ipython dependencies in 3, 4, 7 rounds, and sometime failing in over 16 rounds. That's is not ok.

I'm 100% convinced, after debugging and going line-by-line, that there's a bug here. The number of round required should be stable, not changing between attempts, which it does.

Also, even if the extras and markers are resolved here, half of them can be dropped in the _group_constraint section. There's no markers combination done, which means the only markers that will get through will be the one on the first ireq for the combination.

drcongo 2017-10-9
12

我也碰巧碰到了这个Python 3.6.2/pipenv 8.2。6

原文:

I just stumbled across this too. Python 3.6.2 / pipenv 8.2.6

jc159 2017-10-9
13

@kennethreitz解析 ipython 所需的轮数不是确定性的。 当我跑了六次, 最低的我看到的是 13, 最高的145。 我不认为增加默认的回合数是解决这个问题的好办法。 我所知道的最糟糕的例子是 jupyter 包, 它的解析器属于一个几乎无限的循环。

原文:

@kennethreitz The number of rounds needed to resolve ipython is not deterministic. When I ran it a half-dozen times, the lowest I saw was 13, the highest 145. I do not think that upping the default number of rounds is a good fix to this problem. The worst example I know of is the jupyter package, for which the resolver falls into a practically infinite loop.

vphilippon 2017-10-9
14

我找到了变异的源头:

elif ireq.markers:
    for dependency in self.repository.get_dependencies(ireq):
        yield dependency

产生的 dependency 与此处的 ireq 相同的对象实例. 这意味着:

  • dependency.prepared == True
  • dependency将是下一个迭代中的 ireq 对象。
  • 下一次迭代时,ireq.prepared == True
  • 调用 self.repository.get_dependencies 带有准备好的 ireq 将返回一个空的依赖项集, 因此, 约束的更改 (更具体地说, 是 reqset._prepare_file(self.finder, ireq) 返回和空集)。
  • 在此修补程序之前没有发生此问题, 因为 yield InstallRequirement.from_line(dependency_string, constraint=ireq.constraint) 总是生成一个新实例 ireq , 未准备好。

Quickfix: 设置 dependency.prepared = False 之前的收益稳定的决心。

也许有更好的事情在这里做, 但至少我认为我得到了所发生的事情想通了。

原文:

I've found the source of the variation:

elif ireq.markers:
    for dependency in self.repository.get_dependencies(ireq):
        yield dependency

the yielded dependency is the same object instance as the ireq here. this means:

  • dependency.prepared == True
  • dependency will be the ireq object in the next iteration.
  • On next iteration, ireq.prepared == True
  • Calling self.repository.get_dependencies with a prepared ireq returns an empty set of dependencies, hence the change in constraints (more specifically, reqset._prepare_file(self.finder, ireq) returns and empty set).
  • This did not occur before this patch because yield InstallRequirement.from_line(dependency_string, constraint=ireq.constraint) always yielded a new instance of ireq, unprepared.

Quickfix: Setting dependency.prepared = False before the yield stabilised the resolve.

Maybe there's something better to do here though, but at least I think I got what's happening figured out.

kennethreitz 2017-10-9
15

你能准备一个公关, 我会玩它, 看看它是否仍然符合我们的要求?

原文:

Can you prepare a PR and I'll play with it to see if it still meets our requirements?

vphilippon 2017-10-9
16

@kennethreitz是的, 我会去的。

原文:

@kennethreitz Yes, I'll get on it.

vphilippon 2017-10-9
17

在探索一点, 我注意到, 即使我删除了补丁, 标记仍然存在, 有时只是不同 (指回我的意见, 需要合并标记在 _group_constraints )

如果组合完成, 则 repositories/pypi.pyutils.py 中的修补程序看起来就足以保留标记。我会试着解决这个问题, 这在 pip-tools 中也可能是可取的。

原文:

While exploring a bit, I noticed that even if I remove the patch, the markers are still there, sometime simply being different (pointing back to my comment about needing to combine markers in _group_constraints)

It looks like the patch in repositories/pypi.py and utils.py is sufficient to keep the markers, if the combining is done. I'll try to tackle this, that might be desirable in pip-tools too.

返回
发表文章
jc159
文章数
2
评论数
6
注册排名
60806