Pipenv: Dependências não puderam ser resolvidas. Regressão?

Parece que pipenv adiciona um alfinete estrito aos candidatos da rodada atual.

Isso significa que se em uma próxima rodada, outro pacote exigir uma versão que não corresponda ao candidato atual, ele irá falhar (assim) em vez de tentar encontrar outro candidato. É assim que funciona o algoritmo de resolução: Recalcule totalmente com as novas restrições até que se estabilize.

Não tenho certeza do que está causando isso.
Percebi que para reproduzir isso, tenho que limpar o cache ( --clear ) se já usei pip-tools sozinho antes.
Posso dizer que este não é um bug de pip-tools , e não está diretamente relacionado aos patches de pip-tools (removi todos para tentar, e isso ainda ocorre).
Espero que isso ajude.

Tudo bem, encontrei o culpado:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() contém o próprio req_to_install , fixado, que é errado retornar como uma dependência e pode fazer a resolução da dependência falhar, como aqui, se um pacote subsequente requer uma versão que não se encaixa no candidato atual. Fazer isso pressupõe que nosso primeiro candidato deve ser o certo, ou fracassará.

@kennethreitz Pelo que entendi, era para fazer "resolução de extras profundos". Não tenho certeza se entendi o que isso quer dizer exatamente. Estou pronto para continuar tentando, mas preciso de algumas informações para não ir na direção errada.

Acredito estar vendo o mesmo problema:

$ 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

onde 2.0a1 é claramente uma das opções disponíveis.

Não consigo testar a resolução de dependência em nenhuma versão anterior do pipenv devido a https://github.com/kennethreitz/pipenv/issues/786. Na minha opinião, as correções de bugs críticos devem ser aplicadas a pelo menos algumas das versões principais mais recentes.

Mesmo problema - está reclamando sobre pedidos especificamente.

Este é um bug que acredito estar relacionado ao comentário de @vphilippon . No entanto, não acho que esteja relacionado a # 909.

Exato, não relacionado a # 909.
Como eu disse, vou precisar da entrada de um dos @maintainers para entender o que "resolução de extras profundos" significa exatamente aqui. Eu tenho uma solução, mas gostaria de saber mais para não quebrar nada primeiro.

Ou eu poderia ir em frente e abrir um PR com a correção e discutir lá. Vou ver com meu tempo livre.

@vphilippon Como isso não está em uma organização, mas sim em um @erinxocon e em mim.

O patch para pipocar ​​aqui infelizmente está trancado em algum lugar na cabeça de Kenneth. Acho que não entendo, ou não tive tempo de olhar, o que está acontecendo aqui. Se você encontrar algum tempo para compilar o que acha que pode estar acontecendo, posso tentar ajudar a verificar as suposições. Porém, até então, isso é algo que teremos que ignorar antes de fazer alterações.

@nateprewitt Tudo bem, acrescentarei o máximo que puder. Pegue uma cadeira.

O que há de errado?

Em https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812, observei a fonte do erro: os candidatos selecionados em uma rodada de resolução são adicionados como dependência fixa do próprio candidato diretamente, o que está errado ( mais sobre isso chegando)

Em https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268, encontrei a fonte desse pin: o self.requirements.values() que foi adicionado ao valor de retorno inclui um pin para o pacote atual . Em outras palavras, _prepare_file deveria estar retornando as dependências de um pacote (ou "Uma lista de InstallRequirements adicionais para também instalar"), mas agora ele se inclui, fixado, como sua própria dependência.

Para ajudar a demonstrar por que ter o próprio pacote, fixado, como sua própria dependência, é realmente errado, eis como funciona o algoritmo de resolução de dependências, em resumo:

1. Obtenha initial_constraints_set , uma lista de InstallRequirements (ex: requests>=2.18 ).
2. Defina additional_constraints e candidate como conjunto vazio.
3. Selecione um conjunto de candidate (ex: requests==2.18.4 ) que respeite a união de initial_constraints_set e additional_constraints
4. Para cada candidato, obtenha e combine o conjunto de dependências de todos os candidatos, como additional_constraints (ex: certifi>=2017.4.17 )
5. Se additional_constraints mudou, apague candidate e volte para 3.
6. Devolva o conjunto de candidato, pronto.

Agora, vamos reproduzir o problema com o acima em mente.

Para reproduzir o problema, você precisa deste Pipfile (porque `django-cms 3.4.5 com suporte a Django 1.11 foi lançado):

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

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

E agora 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

• Em uma única rodada de resolução, detectamos que temos que instalar django==* e django-cms==3.4.4 .
• Selecionamos o candidato: django==1.11.6 , django-cms==3.4.4 .
• Pegamos as dependências (vou me concentrar na parte importante):
  
  
  
  • django-cms==3.4.4 requer django<1.11,>=1.8
  
  
  • django requer django==1.11.6 (Isso não é verdade, django não requer a si mesmo! Nenhum pacote requer a si mesmo!)
  
  
• Nós mesclamos o especificador de dependências:
  
  
  
  • Agora exigimos django <1.11,==1.11.6,>=1.8 (você pode ver onde isso vai dar ...)
  
  
• As restrições mudaram, voltando a selecionar o candidato.
• Tente encontrar um candidato para django que seja <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

O que deveria ter acontecido (como acontece em pip-tools , com pip sem patch, com --rebuild para limpar o cache):

• Em uma única rodada de resolução, detectamos que temos que instalar django==* e django-cms==3.4.4 .
• Selecionamos o candidato: django==1.11.6 , django-cms==3.4.4 .
• Pegamos as dependências (vou me concentrar na parte importante):
  
  
  
  • django-cms==3.4.4 requer django<1.11,>=1.8
  
  
  • django requer pytz , mas não django==1.11.6
  
  
• Nós mesclamos o especificador de dependências:
  
  
  
  • Agora exigimos django <1.11,>=1.8 (muito melhor ...)
  
  
• As restrições mudaram, voltando a selecionar o candidato.
• Tente encontrar um candidato para django que seja <1.11,>=1.8 :
  
  
  
  • Seleciona um novo candidato django , provavelmente django==1.10.8
  
  
• Calcula dependências, continua e resolve com alegria.

O que fazer a partir daqui?

Bem, remover self.requirements.values() da devolução em _prepare_file corrige este problema, posso confirmá-lo. Infelizmente, não descobri exatamente por que foi adicionado lá.

Talvez Kenneth quisesse retornar um objeto InstallRequirement para o próprio candidato após realizar alguma operação nele a fim de obter informações relacionadas à "resolução de extras profundos" (estou realmente me esforçando aqui). Eu poderia tentar corrigir o patch para manter aquele objeto InstallRequirement no valor retornado, mas liberando-o primeiro. Tenho certeza de que não foi intencional e, mesmo que fosse, está quebrado.

Eu acho que é isso. ☕️

@vphilippon , muito obrigado por colocar uma análise tão detalhada! Isso definitivamente esclarece as coisas para mim.

Revendo o log de commits, isso foi adicionado em ae4591b2 e, como você disse, não está claro por que foi adicionado. Acho que a próxima etapa é reunir um caso de teste com falha para isso e um caso de teste funcional para instalar "dependências profundas". Não há nenhum ticket levantando esse problema e as mensagens de confirmação não são úteis, então estamos apenas supondo neste ponto.

Olhando para o código, acho que isso está tentando resolver tendo uma declaração como requests[security] que pode ter uma dependência certifi[some-extra] que também precisa ser resolvida. Essa é a única coisa que consigo pensar, pelo menos. Aposto que há algo no universo Django que está fazendo isso e, se pudermos encontrar um exemplo, isso nos permitirá escrever um teste.

Então! Se alguém quiser trabalhar para colocar esses testes juntos, garantindo que o primeiro falhe e a "dependência profunda" funcione, podemos remover a declaração self.requirements.values() .

@nateprewitt Aqui está algo que acho que descreve o que você quis dizer:
https://github.com/vphilippon/testdeepextra

Mas, a resolução profunda "foo [a] depende da barra [b]" parece já estar ok em pip-tools , pois pode ser testada com aquele repo.
Portanto, esse patch pode não ser exatamente isso, já que presumo que seja para algo que não estava funcionando originalmente em pip-tools . A menos que seja para algum caso específico, não consegui testar aqui.

De qualquer forma, ainda podemos testar o comportamento de resolução do extra de pipenv com aquele repo (o que não tenho tempo de fazer imediatamente), com e sem esse patch, e ver se ele tem algum efeito, e / ou compare com a saída de pip-tools . Pelo menos temos um ponto de partida.

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. Recebi este erro quando a versão dos pacotes é igual a '*', mas quando mudo para a versão conhecida, como '== 0.1.2', funciona bem.
2. Infelizmente, quando eu digito pipenv install sanic-plugins-framework==0.5.0.dev20171225 , recebo de volta esta grande mensagem de erro. Talvez todas as versões acima não sejam maiores que '0.5.0.dev20171225'
3. Como devo fazer para cobrir isso

pipenv lock —pre —clear

Obrigado @Jasonsey por compartilhar sua parte e a @techalchemy por sua resposta.
Tive um problema específico com sanic-plugins-framework e adicionar a sinalização --pre (_Permitir pré-lançamentos._) me ajudou a instalar o pacote 🙌

Isso já foi consertado? Ainda estou tendo o mesmo comportamento errôneo.
https://github.com/pypa/pipfile/issues/114