Pipenv: Не удалось разрешить зависимости. Регресс?

Похоже, что pipenv добавляет к кандидатам текущего раунда строгий контакт.

Это означает, что если в следующем раунде другим пакетам потребуется версия, не соответствующая текущему кандидату, он потерпит неудачу (вот так) вместо попытки найти другого кандидата. Вот как работает алгоритм разрешения: полностью пересчитайте с новыми ограничениями, пока он не стабилизируется.

Я не уверен в причинах этого.
Я заметил, что для воспроизведения этого мне нужно очистить кеш ( --clear ), если раньше я использовал только pip-tools .
Я могу сказать, что это не ошибка 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 явно является одним из доступных вариантов.

Я не могу протестировать разрешение зависимостей в любых более старых версиях pipenv из-за https://github.com/kennethreitz/pipenv/issues/786. На мой взгляд, критические исправления ошибок следует применять по крайней мере к некоторым из самых последних основных версий.

Та же проблема - он конкретно жалуется на запросы.

Я считаю, что это ошибка, связанная с комментарием @vphilippon . Однако я не думаю, что это связано с № 909.

Точно, не относящийся к # 909.
Как я уже сказал, мне понадобится информация от одного из @maintainers, чтобы понять, что именно здесь означает «глубокое разрешение дополнительных

Или я мог бы пойти дальше и открыть PR с исправлением и обсудить там. Посмотрю в свободное время.

@vphilippon Поскольку это не организация, а личное репо для Кеннета, у нас, к сожалению, нет удобного тега @, чтобы получить доступ ко всем нам. Я предлагаю просто пинговать @erinxocon и себя.

К сожалению, патч для пипа заперт где-то в голове Кеннета. Я не думаю, что понимаю или у меня было время взглянуть на то, что здесь происходит. Если вы найдете время для компиляции того, что, по вашему мнению, может происходить, я могу попытаться помочь проверить предположения. Однако до тех пор, прежде чем вносить изменения, нам придется осторожно действовать.

@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_constraints и candidate как пустой набор.
3. Выберите набор candidate (например, requests==2.18.4 ), который соответствует объединению initial_constraints_set и additional_constraints
4. Для каждого кандидата получите и объедините набор зависимостей всех кандидатов, как additional_constraints (например: certifi>=2017.4.17 )
5. Если additional_constraints изменилось, очистите candidate и вернитесь к 3.
6. Верните набор кандидатов, готово.

Теперь давайте воспроизведем проблему с учетом вышеизложенного.

Чтобы воспроизвести проблему, вам понадобится Pipfile (потому что был выпущен `django-cms 3.4.5 с поддержкой Django 1.11):

[[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.6 , django-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.6 , django-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
  
  
• Вычисляет зависимости, продолжает работать и успешно разрешает.

Что делать дальше?

Что ж, удаление self.requirements.values() из возврата в _prepare_file решает эту проблему, я могу это подтвердить. К сожалению, я точно не понял

Возможно, Кеннет хотел вернуть объект InstallRequirement для самого кандидата после выполнения с ним некоторой операции, чтобы получить информацию, относящуюся к «разрешению глубоких дополнений» (здесь я действительно растягиваюсь). Я мог бы попытаться исправить патч, чтобы сохранить этот дополнительный объект InstallRequirement в возвращаемом значении, но сначала открепив его. Я почти уверен, что это было не намеренно, и даже если это было так, все было сломано.

Думаю, все. ☕️

@vphilippon ,

Возвращаясь к журналу фиксации, это было добавлено в ae4591b2, и, как вы сказали, довольно неясно, почему это было добавлено. Я думаю, что следующим шагом будет составление неудачного тестового примера для этого и рабочего тестового примера для установки «глубоких зависимостей». Нет ни одного тикета, поднимающего эту проблему, и сообщения фиксации бесполезны, поэтому мы просто догадываемся на данный момент.

Глядя на код, я думаю , requests[security] которое может иметь зависимость certifi[some-extra] которую также необходимо разрешить. Это единственное, о чем я могу думать по крайней мере. Держу пари, что во вселенной Django есть что-то, что делает это, и если мы сможем найти пример, который позволит нам написать тест.

Так! Если кто-то захочет поработать над объединением этих тестов, чтобы убедиться, что первый из них не сработает и «глубокая зависимость» работает, мы можем рассмотреть возможность удаления объявления self.requirements.values() .

@nateprewitt Вот кое-что, что, я думаю, описывает то, что вы имели в виду:
https://github.com/vphilippon/testdeepextra

Но глубокое разрешение «foo [a] зависит от bar [b]» кажется уже приемлемым в pip-tools , поскольку оно может быть протестировано с этим репо.
Так что этот патч может быть не совсем таким, поскольку я предполагаю, что он для чего-то, что изначально не работало в 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 за то, что поделился своим мнением, и
У меня была проблема именно с sanic-plugins-framework , и добавление --pre (флаг _Allow pre-releases._) помогло мне установить пакет 🙌

Было ли это когда-нибудь исправлено? У меня все еще такое же ошибочное поведение.
https://github.com/pypa/pipfile/issues/114