Pip: Erro com `import pip` no pip 9.0.2

Posso confirmar isso também. Apenas prestes a arquivar mesmo problema.

Este é um engano de # 5079 - importar pip não é um caso de uso suportado (e nunca foi).

Vamos lá .. fazer uma grande mudança em uma única versão x.x.PATCH ? Para um método de nível superior chamado "principal"? Eu acho que é uma forma muito pobre ..

Isso também quebrou o Anaconda e eu criei a mesma solução que @Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

Erros estão sendo relatados em muitos projetos.

Esse erro também me incomodou quando eu estava tentando usar o pip para atualizar meu navegador anaconda.

Existe alguma chance de obtermos um 9.0.3 que corrija isso - idealmente em breve?

Isso já está afetando muitos projetos importantes (Anaconda, SpaCy, Zappa), e há mais de 850 mil usos disso apenas no GitHub que agora estão quebrados por essa suposta atualização de versão "patch".

Você pode pelo menos reverter essa grande mudança em 9.0.3 e então _announce_ para downstreams sua intenção de mudar esse comportamento para uma futura versão 10.xx ou pelo menos 9.xx?

Também não queremos usar uma versão mais antiga, mas foi exatamente isso que acabamos fazendo. 9.0.2 não existe dentro do nosso ambiente de CI, pelo menos por enquanto.

Também vendo esse hit em alguns projetos do OpenStack.

Pip 10 deve sair em cerca de um mês. Pelo que entendi, o problema é com o código que usa import pip para acessar a funcionalidade interna do pip. Nunca suportamos esse uso oficialmente e documentamos explicitamente essa falta de suporte há algum tempo (embora apenas na versão "mais recente" dos documentos em https://pip.pypa.io/en/latest/user_guide /#using-pip-from-your-program, porque não tivemos uma nova versão estável desde que a seção doc foi adicionada). Também anunciamos uma reorganização dos internos para deixar claro que o uso de APIs internas não é compatível, em outubro passado (consulte https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Essa alteração, que está no pip 10, interromperá qualquer uso desse tipo, independentemente do pip que uma possível versão do pip 9.0.3 faria. Portanto, é difícil ver isso como uma quebra repentina e inesperada.

Se @dstufft quiser fazer uma versão de emergência 9.0.3, estou bem com isso. Mas será apenas um benefício de muito curto prazo, e estou um pouco desapontado que as pessoas ainda não tenham se afastado de import pip . As pessoas atingidas por esse problema ainda precisarão se preparar para o pip 10 e devem entender que simplesmente mudar para import pip._internal não é algo que apoiaremos ou recomendaremos.

Propostas para reintroduzir algum nível de suporte à API são certamente uma opção (veja #5080, por exemplo), mas, neste estágio, é tarde demais para que essas alterações cheguem ao pip 10.

Sem avisos sendo levantados pelo código para aqueles que usam a maneira antiga, nada denotando isso como "interno" começando com _, e isso apenas sendo um bug de correção, eu realmente acho que é muito fácil ver isso como uma quebra repentina e inesperada .

Sim, este é o tipo de mudança que as pessoas podem esperar de uma atualização de versão MAJOR . Isso seria bom.

Infelizmente, essa grande mudança veio em uma atualização PATCH , que _supostamente conserta as coisas, não as quebra_. Isso é exatamente o oposto do versionamento semântico. E, como resultado, estamos vendo grandes danos em todo o ecossistema Python.

Você deve reverter essa alteração o mais rápido possível em outra atualização PATCH e, em seguida, fazer com que a principal alteração importante venha com a atualização de versão MAJOR . Agora que você já quebrou tudo para todos prematuramente, acho que eles estarão mais cientes de que a grande mudança real está chegando.

Eu também acho que é um policial dizer que isso já foi documentado e anunciado, considerando que _não_ foi documentado na documentação estável , e que o anúncio dizia que o intervalo aconteceria _para a versão principal_, não para um patch por mês prévio.

Por favor, apenas salve a todos uma enorme dor de cabeça, reverta esse problema e comece realmente a aderir ao versionamento semântico.

@Miserlou OK, entendo seu ponto - direcionamos a mudança de renomeação interna para o pip 10 porque é uma versão principal. Eu realmente não conheço os drivers para o lançamento do patch - @dstufft me deu um ping sobre isso e aparentemente é para evitar quebras significativas para usuários do Mac OS quando um prazo iminente para o suporte a TLS nos atinge, que é antes do lançamento do pip 10. Esperávamos que os problemas fossem significativos o suficiente para garantir um lançamento de patch de curto prazo. Certamente não havia intenção de quebrar o uso existente.

Eu tenho que deixar a decisão de um follow-up 9.0.3 para @dstufft - não tenho os detalhes do que aconteceu no 9.0.2 ou sei se é possível identificar como corrigir esse problema. E não posso julgar se puxar o 9.0.2 por completo será um benefício geral, pois não tenho ideia de quantas pessoas são afetadas pelo problema do Mac OS. Eu entendo que (pelo menos para algumas pessoas) fixar em 9.0.1 é uma solução, então essa pode acabar sendo a opção menos ruim.

O problema de TLS do macOS afetará todos que usam um sistema Python no macOS<10.13

Tenho que deixar a decisão de um follow-up 9.0.3 para @dstufft

Estou na mesma posição que @pfmoore.

A solução alternativa, se você tiver disponível para você, é verificar a ordem das importações e testar a movimentação do pip de importação acima de outras importações de pacotes (especificamente, importar pip _antes_ de importar solicitações parece resolver alguns casos). (Observe que isso ainda implica o uso de componentes internos do pip, que não são oficialmente suportados.)

Mesmo problema aqui com pip 9.0.2 em um gitlab-ci com docker python 3.4: KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

FYI, 9.0.2 foi lançado com compilações quebradas:

Referência Travis-CI: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

Concedido os erros podem não estar relacionados, embora isso cheire apenas como um "lançamento apressado" ...

@pfmore

Se @dstufft quiser fazer uma versão de emergência 9.0.3, estou bem com isso. Mas será apenas um benefício de muito curto prazo, e estou um pouco desapontado que as pessoas ainda não tenham se afastado do pip de importação. As pessoas atingidas por esse problema ainda precisarão se preparar para o pip 10 e devem entender que simplesmente mudar para importar pip._internal não é algo que apoiaremos ou recomendaremos.

Eu não posso acreditar que esta é uma declaração do proprietário deste repositório... Você literalmente acabou de dizer "f*ck versioning semântico" e "quem precisa de uma política de depreciação de qualquer maneira".

pip sempre foi documentado como NÃO tendo uma API python consumível, estou desapontado com as pessoas que, mesmo nesse ponto, tentam reverter o carma do "eu avisei há alguns anos"

@RonnyPfannschmidt Isso é como dizer "Nós dissemos a você 100 vezes que você não tem permissão para dirigir acima do limite de velocidade" e, em seguida, impor o limite de velocidade substituindo todos os carros a motor por carros de flintstone, para que as pessoas não possam ultrapassar o limite de velocidade limite de velocidade mais.

você acabou de demonstrar perfeitamente que a reviravolta de palavras tão ruim - o ditado era "não confie nisso ele vai quebrar" - agora ele quebrou e de repente o projeto que lhe disse antes que ele vai quebrar é o culpado

que apenas colocando a culpa porque você não gosta de ser o culpado

@RonnyPfannschmidt

que apenas colocando a culpa porque você não gosta de ser o culpado

Então você está dizendo que sou culpado por usar pacotes de terceiros que dependem de um recurso não documentado do pip. Talvez, eu seja... Eu deveria ter examinado esses pacotes de terceiros para esses erros e enviado um problema ou, melhor ainda, um PR.

Mas vamos encarar a realidade: existem muitos projetos por aí que são usados ​​na produção e agora estão quebrados. Não é uma questão de moral, não é uma questão de quem é a culpa. É uma questão de "você pode corrigir isso e fornecer um aviso / suspensão de uso adequado".

Se um pacote de terceiros que você usa quebrar porque depende de APIs internas não documentadas e não garantidas, parece-me que você deve registrar um bug nesse pacote.

Há uma linha fácil de descobrir entre quais partes de pip são e não são destinadas ao consumo de terceiros, e eu não apoio a tentativa de forçar seus desenvolvedores a manter APIs internas que nunca deveriam ter sido consumidos por pacotes de terceiros. Eu não apoio tratar isso como culpa dos desenvolvedores pip e enviar usuários irritados para eles. Se você quer ficar com raiva de alguém, fique com raiva de qualquer pacote que você usa que dependia de APIs internas e pressione seus mantenedores para corrigir seu próprio código.

@anx-ckreuzberger

Eu não posso acreditar que esta é uma declaração do proprietário deste repositório... Você literalmente acabou de dizer "f*ck versioning semântico" e "quem precisa de uma política de depreciação de qualquer maneira".

Embora eu entenda a frustração aqui, estou ficando cada vez mais irritado com a disposição das pessoas de culpar os mantenedores do pip por coisas que nunca prometemos.

Se você quiser fazer acusações como essa, por favor, apoie-as com

1. Um ponteiro para uma declaração de qualquer um dos mantenedores do pip que suportamos o uso da API interna do pip no código do usuário.
2. Um ponteiro para uma declaração de qualquer um dos mantenedores do pip que o pip usa versionamento semântico.

Eu não acho que você vai encontrar essa evidência ...

Então você está dizendo que sou culpado por usar pacotes de terceiros que dependem de um recurso não documentado do pip.

Não, mas acusar os mantenedores do pip ao invés desses projetos não é aceitável. Estamos tentando ajudá-lo, mas não podemos ser responsabilizados pelo que esses projetos fazem. Exponha suas queixas com eles.

Mas vamos encarar a realidade: existem muitos projetos por aí que são usados ​​na produção e agora estão quebrados. Não é uma questão de moral, não é uma questão de quem é a culpa. É uma questão de "você pode corrigir isso e fornecer um aviso / suspensão de uso adequado".

Tentamos dar um aviso. Enviamos anúncios meses atrás, adicionamos documentos explicando a situação e respondemos consistentemente a problemas no rastreador informando que o uso de APIs internas não é compatível. Adicionar depreciações está longe de ser tão fácil quanto você sugere, pois o próprio pip lançaria esses avisos (ou haveria uma maneira de o pip desativá-los, que outros apenas copiariam - já estamos ouvindo falar de pessoas planejando apenas import pip._internal , então mesmo essa mudança não irá pará-los :disappointed:).

Quanto a "consertar" isso, admito alegremente que a versão 9.0.2 foi lançada rapidamente para resolver um problema urgente, e não antecipamos esse problema. Talvez liberar um 9.0.3 com uma vida útil de 2-3 semanas seja uma coisa razoável a fazer, eu acho que não, mas afirmei que consideraremos isso. Eu pessoalmente não posso concordar em fazê-lo, pois não sou eu quem está envolvido nas versões 9.0.x. Estou trabalhando no pip 10, o que tornará todo esse debate irrelevante, então esta é provavelmente minha última palavra sobre esse assunto - preciso me concentrar em coisas relacionadas a esse lançamento.

Meu conselho pessoal:

1. Fixe em 9.0.1 se você for afetado por isso e precisar de uma solução alternativa agora .
2. Esteja preparado para o pip 10, quando todas as dependências que você tem atualmente estão quebradas porque usam APIs internas do pip serão quebradas novamente. Empurre essas dependências para agir com base nas informações que fornecemos há meses e fique feliz por ter recebido um aviso prévio de que isso aconteceria.
3. Se o pip 9.0.3 for liberado, remova o pino.
4. Por favor , teste o pip 10 beta quando ele for lançado e relate quaisquer problemas às partes relevantes (projetos de terceiros se eles estiverem chamando pip internamente, nós se você estiver chamando pip).

Eu experimentei o mesmo problema com pip 9.0.2 e Python 2.7.14 em um contêiner docker.
No entanto, não consigo reproduzir o problema na minha máquina dev fora de um contêiner docker.
Eu procurei por uma importação de pip (grep para import.pip , from.pip , \'pip , \"pip ), mas não consegui encontrar nada.
Nós do Plone estamos usando um mecanismo para incluir automaticamente configurações de pacotes incluídos em um arquivo setuptools setup.py, o que parece suspeito - mas novamente - este está usando apenas __import__ e nada do pip AFAIcansee.

Esta é a parte relevante do traceback:

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

Tanto quanto eu entendo, apenas importar pip - sem usá-lo - já quebra. Este não é um comportamento de bom cidadão na terra do Python. Não suportar o uso/não fornecer uma API pública é uma coisa, apenas quebrar na importação outra. Isso afeta muito código de inspeção automática.

Pense desta forma: pip é um utilitário de linha de comando, não uma biblioteca. O fato de ser escrito em Python é irrelevante. Essa é a realidade da questão.

@pfmore

Embora eu entenda a frustração aqui, estou ficando cada vez mais irritado com a disposição das pessoas de culpar os mantenedores do pip por coisas que nunca prometemos.

Pense desta forma: pip é um utilitário de linha de comando, não uma biblioteca. O fato de ser escrito em Python é irrelevante. Essa é a realidade da questão.

A linha inferior é que realmente não importa o que você prometeu. O que importa é o que você fez e qual é a situação resultante. Talvez você tenha pensado nisso como um utilitário de linha de comando. Mas você o lançou como uma biblioteca. Essa é a realidade do assunto:

Você lançou uma biblioteca com o Recurso X. As pessoas começaram a usar o Recurso X. Claro, você disse "caras, por favor, não usem o Recurso X". Mas você continuou lançando-o com o Feature X. Por anos. E assim as pessoas continuaram usando. Dezenas, talvez centenas, de milhares de projetos, grandes e pequenos, use-o agora. De repente, você o remove em uma pequena atualização sem aviso adequado.

O que você acha que acontece a seguir?

No curto prazo, as pessoas apenas fixarão a versão antiga e não a desvincularão, a menos que haja uma boa razão.

A longo prazo... bem, depende de quantas pessoas decidirem que seria mais rentável substituí-lo do que consertar tudo o que você quebrou.

@pfmoore você vê algo suspeito no traceback que mencionei acima? Não há uso de nenhum AFAIK interno de pip. É interessante que a maioria das pessoas tenha esses problemas nos contêineres do docker.

@ todos, acusar os mantenedores de código quebrado não ajuda a resolver o problema.

Pense desta forma: pip é um utilitário de linha de comando, não uma biblioteca. O fato de ser escrito em Python é irrelevante. Essa é a realidade da questão.

Fato: Não pode ser importado, se importado mesmo por auto-inspeção de código por algum motivo: todas as quebras. Suponho que isso aconteça no caso de @thet .
Conclusão: o pip deve se isolar do namespace virtualenv/venv global ou atual do Python no qual instala os pacotes. Dessa forma não o polui e nem mesmo a importação por acidente acontece.

Em primeiro lugar, desculpe se acusei os mantenedores do repositório de código defeituoso. Qualquer acusação foi feita por frustração e, se for o caso, aponta para o fato de que IMHO a versão 9.0.2 é pela definição de semver uma versão de patch (embora @pfmoore tenha deixado claro que pip não está necessariamente usando semver - o que é outra questão para outro dia, eu acho).

@MikeHart85

No curto prazo, as pessoas apenas fixarão a versão antiga e não a desvincularão, a menos que haja uma boa razão.
A longo prazo... bem, depende de quantas pessoas decidirem que seria mais rentável substituí-lo do que consertar tudo o que você quebrou.

Bastante. Quero dizer, veja os gerenciadores de pacotes JavaScripts: npm, bower, yarn, o que for lançado no próximo ~ano~ semana

Não, mas acusar os mantenedores do pip ao invés desses projetos não é aceitável. Estamos tentando ajudá-lo, mas não podemos ser responsabilizados pelo que esses projetos fazem. Exponha suas queixas com eles.

Entendo que minhas (nossas?) queixas nesta questão podem ser mal direcionadas. Embora você tenha que admitir que é realmente difícil convencer alguém de que isso é culpa de mantenedores de terceiros.

Tentamos dar um aviso. Enviamos anúncios meses atrás, adicionamos documentos explicando a situação

Isso foi para pip 9.0.2 ou para pip 10? Se fosse para o pip 9.0.2, eu acharia legal se houvesse uma nota no Changelog . De qualquer forma, obrigado por ser muito proativo no desenvolvimento do pip 10 e enviar anúncios sobre não usar import pip , isso é bom! Mantem!

Adicionar depreciações está longe de ser tão fácil quanto você sugere, pois o próprio pip lançaria esses avisos (ou haveria uma maneira de o pip desativá-los, que outros apenas copiariam - já estamos ouvindo falar de pessoas planejando apenas import pip._internal, então mesmo essa mudança não os deixará desapontados).

Eu não acho que isso seria muito difícil... Você já tem isso no __init__.py :

if __name__ == '__main__':
    sys.exit(main())

Que tal adicionar outro?

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

edit : Você pode até criar uma exceção aqui se quiser ser "estrito" sobre isso e adicionar instruções semelhantes aos submódulos.

O fato de que as pessoas vão contornar isso, é outra coisa. Se você quiser hackear uma biblioteca, sempre poderá fazer engenharia reversa. Você sempre pode encontrar uma maneira de contornar isso. Mas você não deve considerar todas as maneiras de contornar isso em suas decisões de design.

A longo prazo... bem, depende de quantas pessoas decidirem que seria mais rentável substituí-lo do que consertar tudo o que você quebrou.

Eu sempre acho essa "ameaça" divertida. Ele vem com um mal-entendido fundamental sobre a quantidade de esforço que é colocado em algo como pip e quanto isso realmente custa (e quão pouco as pessoas estão dispostas a pagar por isso). Se você sente que é capaz de fazer melhor, então faça isso, eu (e eu presumo que os outros) damos as boas-vindas. Uma quantidade não trivial de esforço nos últimos anos tem sido documentar e projetar padrões com um dos objetivos explícitos de tornar possível que tal coisa aconteça.

É importante manter um senso de perspectiva sobre essas coisas. Existem .. menos de 15? 20? pessoas comentando sobre como isso os quebrou (embora sempre haja um problema de "ponta do iceberg" com essas métricas), enquanto isso o pip 9.0.2 já é o segundo instalador mais usado na semana passada (contando os dias, ele nem existia for) e baixou 17 milhões de arquivos do PyPI desde que foi lançado. Olhando apenas para o último dia, é 80% do caminho para ultrapassar o pip 9.0.1 como o instalador mais usado no PyPI.

Então, embora eu reconheça que isso quebrou as coisas para algumas pessoas, é um número relativamente pequeno de pessoas fazendo coisas sem suporte ou em situações bastante extremas.

Se eu encontrar tempo, posso tentar cortar um 9.0.3, principalmente para resolver o caso em que @thet se deparou com um importador automático tentando importar coisas, e eles não estão realmente tentando usar APIs internas do pip de qualquer forma. Se isso também acabar resolvendo o comportamento das pessoas que usam as APIs internas do pip, não vou me esforçar para quebrá-las especificamente, mas se isso não acontecer, também não vou me esforçar para consertar especificamente também.

Por favor, note que leva muitas horas para liberar um 9.0.x neste momento (as coisas divergiram em master o suficiente para exigir alguns ajustes para fazer um lançamento) e isso não conta o tempo necessário para depurar e corrigir o problema real. Se você quiser aumentar a chance de que isso aconteça, fazer essa depuração e correção e fornecer um patch (ou uma ramificação da tag 9.0.2 em seu próprio fork) é a melhor maneira de fazer isso.

Em primeiro lugar, desculpe se acusei os mantenedores do repositório de código defeituoso. Qualquer acusação foi feita por frustração

Obrigada. A frustração é grande aqui, e eu entendo isso.

Que tal adicionar outro?

Boa ideia - gostaria que tivéssemos pensado nisso há algum tempo. Claro, não há nenhum ponto real agora, pois o namespace interno será reorganizado no pip 10, então é tarde demais. Certamente me lembrarei desse truque no futuro.

Isso foi para pip 9.0.2 ou para pip 10?

Para 10,0. Não havia a intenção original de lançar um 9.0.2, só o fizemos como uma versão de emergência para que os usuários do Mac OS não perdessem todo o acesso ao PyPI quando as alterações do TLS entrarem em vigor.

@dstufft respondeu aqui de forma muito mais completa, então acho que isso está tão resolvido quanto é provável que esteja por enquanto.

Eu sempre acho essa "ameaça" divertida.

Não é uma ameaça em tudo, peço desculpas se foi assim.

É uma observação sobre algo que acontece com muita frequência no mundo do software. As pessoas não trabalham com suas promessas ou intenções. As pessoas trabalham com o produto que você entrega. Se o seu produto tem um recurso do qual muitas pessoas passam a depender, você não pode mais arrancá-lo de seus pés. Se você fizer isso, eles começarão a ver seu produto como quebrado. Se a única explicação que você fornece é "bem, nós nunca prometemos isso de qualquer maneira", então eles começam a ver sua falta de vontade de reconhecer suas preocupações como uma responsabilidade.

Quanto mais isso acontece, maior o desejo e a demanda por uma alternativa. Claro, as pessoas subestimam quanto trabalho isso leva. Mas isso só os torna mais , não menos, propensos a começar a trabalhar em um. Uma vez que a bola está rolando, ela tem vida própria.

Alternativas nem sempre são boas. Eles tendem a tornar as coisas confusas. Pessoalmente, eu preferiria um único gerenciador de pacotes. Para tudo. Mas vou me contentar com um único gerenciador de pacotes para Python.

Quando as pessoas relatarem que você quebrou um recurso, intencional ou não, considere explicar brevemente por que você teve que quebrá-lo ou por que mantê-lo não era viável, em vez de descartar as preocupações com "isso não foi suportado o tempo todo".

Ei @dstufft , obrigado por entrar na conversa. Este tópico está ficando muito quente!

Primeiramente, parabenizo pelo seu trabalho! Eu sei que a manutenção é uma tarefa sem fim e ingrata, e imagino que só piora quando você gerencia um projeto tão grande e popular quanto pip !

Agora, para o problema em questão: Embora vinte _mantenedores_ tenham relatado esse problema até agora, eu sei que já está afetando milhares de _pessoas_ - alguns dos projetos afetados são enormes por si só: Anaconda, OpenStack, SpaCy, Zappa e têm muitas dezenas de milhares de usuários. Eu sei que nosso canal do Slack está repleto de discussões sobre isso. (Literalmente, enquanto eu estava digitando isso, um novo problema apareceu.)

Claramente, existem muitos projetos Python importantes que precisam da capacidade de inspecionar programaticamente seus ambientes. Esta é uma coisa totalmente razoável que precisa ser capaz de fazer. Além disso, a documentação nunca alertou contra isso - e ainda não alerta! (Clique no link Docs do README deste repositório!)

Acho que a situação até agora é:

• Dado o formato da string de versão, todos nós acreditamos que os mantenedores do pip estão seguindo o versionamento semântico
• Os mantenedores do pip lançaram um "patch" que introduziu uma mudança massiva
• Essa mudança não foi anunciada e não foi documentada - e presumo, inesperada e não intencional
• Agora, apenas chamar import pip imediatamente quebra um programa, que é extremamente hostil ao desenvolvedor
• Isso está causando grandes dores de cabeça em todo o ecossistema Python
• A documentação não (e _ainda_ não - clique no link Docs no README deste repositório) não adverte contra o uso pip programaticamente.
• Não houve anúncio de que import pip causaria esse dano em uma atualização PATCH - esse anúncio veio para uma versão que _ainda não foi lançada_.
• Essa mudança nem foi mencionada no Changelog
• Não queremos substituir o pip ou os desenvolvedores do pip! Nós te amamos!
• ..mas não queremos que este tipo de coisa volte a acontecer!
• ..então queremos que sempre seja seguido!
• Nós realmente gostaríamos de outro PATCH que desfaça essa grande mudança!

A necessidade de uma maneira programática de inspecionar um ambiente em um mundo pip>=10.0.0 é um tópico para outra discussão, mas o fato em questão é que nunca nos disseram que não deveríamos usar pip programaticamente no pip <=9 mundo, e houve uma mudança massiva e não anunciada, e realmente gostaríamos de vê-la revertida porque está afetando negativamente milhares de pessoas.

Obrigado novamente,
Rico

Primeiro de tudo: obrigado aos mantenedores do pip por seus esforços e pelas percepções dentro do projeto. Eu acredito que isso realmente ajuda os outros a entender o problema (embora possa valer a pena escrever um artigo resumido no blog sobre isso).

@dstufft

É importante manter um senso de perspectiva sobre essas coisas. Existem .. menos de 15? 20? pessoas comentando sobre como isso os quebrou (embora sempre haja um problema de "ponta do iceberg" com essas métricas), enquanto isso o pip 9.0.2 já é o segundo instalador mais usado na semana passada (contando os dias, ele nem existia for) e baixou 17 milhões de arquivos do PyPI desde que foi lançado. Olhando apenas para o último dia, é 80% do caminho para ultrapassar o pip 9.0.1 como o instalador mais usado no PyPI.

Tenho certeza de que a métrica é fortemente influenciada por todos os comandos automatizados pip install pip --upgrade dos sistemas de Integração/Entrega Contínua (eles devem usar caches e, portanto, não precisam reinstalar pacotes do pypi o tempo todo; mas em ao mesmo tempo, também não se deve fazer import pip ... é assim que funciona o mundo da TI).

O fato de (menos de) 15 pessoas terem reclamado sobre isso deve mostrar duas coisas:

1. Eu não acho que muitas pessoas usem o 9.0.2 (em produção) ainda, alguns ainda podem estar tentando depurar esse problema e irão corrigi-lo "temporariamente" usando o pip 9.0.1 até que seja resolvido (ou para sempre .. .) - também, algumas pessoas podem não ter notado que algo ainda não está funcionando...
2. Já tem gente falando sobre isso em 2 dias do lançamento. Mais pessoas terão esse problema. Aguarde 2 semanas e você pode acabar tendo 100 pessoas reclamando (por exemplo, quando eles terminam um sprint e implantam no controle de qualidade/preparação). Neste momento você realmente não sabe quantas pessoas serão afetadas por essa mudança.

De qualquer forma, conversar e discutir sobre esse problema dá às pessoas um bom exemplo de por que nunca se deve confiar em APIs internas, e esperamos que alguns mantenedores de pacotes de terceiros atualizem seus projetos por causa do que foi falado aqui.

Claramente, existem muitos projetos Python importantes que precisam da capacidade de inspecionar programaticamente seus ambientes. Esta é uma coisa totalmente razoável que precisa ser capaz de fazer. Além disso, a documentação nunca alertou contra isso - e ainda não alerta! (Clique no link Docs do README deste repositório!)

Não está claro para mim por que você teria que alertar contra isso. O uso de pip como qualquer outra coisa que não seja uma ferramenta de linha de comando é completamente indocumentado . Pesquisando a documentação, não vejo nenhuma referência à importação de pip . É como reclamar porque você vinculou alguns .so usados ​​pelo Chrome e eles quebraram a compatibilidade da ABI.

A interpretação usual do SemVer é que ele se aplica à interface pública suportada (neste caso, a CLI), não aos internos não documentados. Qualquer pessoa que use os internos deve fixar suas versões pip de qualquer maneira , pois elas estão sujeitas a alterações arbitrárias.

Não há nada para reverter realmente. Correções de backport para evitar que uma parte significativa de usuários no macOS não consiga acessar o PyPI em um futuro próximo tem um bug quando aplicado à base de código 9.0.x que parece se expressar apenas em condições sem suporte. O único caminho a seguir é fazer trabalho adicional para resolver esse bug na série 9.0.x. Como eu disse, se eu encontrar tempo, tentarei fazer isso, se você quiser aumentar a chance de isso acontecer, forneça um patch.

A documentação não adverte contra isso porque não é possível fornecer uma lista exaustiva de coisas que você poderia fazer com o pip, mas que não é suportada. Em vez disso, confiamos na abordagem bastante comum de documentar o que é suportado e qualquer coisa não documentada deve ser considerada como não suportada (e se você quiser confiar em algo que não está documentado, abrir um problema solicitando que seja documentado e, portanto, suportado ).

A longo prazo, é provável que avancemos para um esquema de lançamento baseado em datas para (espero) remover qualquer confusão sobre se estamos sempre ou não.

Enviado do meu iPhone

Em 20 de março de 2018, às 11h02, Rich Jones [email protected] escreveu:

Ei @dstufft , obrigado por entrar na conversa. Este tópico está ficando muito quente!

Primeiramente, parabenizo pelo seu trabalho! Eu sei que a manutenção é uma tarefa sem fim e ingrata, e imagino que só piora quando você gerencia um projeto tão grande e popular quanto o pip!

Agora, para o problema em questão: Embora vinte mantenedores tenham relatado esse problema até agora, eu sei que já está afetando milhares de pessoas - alguns dos projetos afetados são enormes por si só: Anaconda, OpenStack, SpaCy, Zappa e têm muitas dezenas de milhares de usuários. Eu sei que nosso canal do Slack está repleto de discussões sobre isso. (Literalmente, enquanto eu estava digitando isso, um novo problema apareceu.)

Claramente, existem muitos projetos Python importantes que precisam da capacidade de inspecionar programaticamente seus ambientes. Esta é uma coisa totalmente razoável que precisa ser capaz de fazer. Além disso, a documentação nunca alertou contra isso - e ainda não alerta!

Acho que a situação até agora é:

Dado o formato da string de versão, todos nós acreditamos que os mantenedores do pip estão seguindo o versionamento semântico
Os mantenedores do pip lançaram um "patch" que introduziu uma mudança massiva
Essa mudança não foi anunciada e não foi documentada - e presumo, inesperada e não intencional
Agora, apenas chamar import pip quebra imediatamente um programa, que é extremamente hostil ao desenvolvedor
Isso está causando grandes dores de cabeça em todo o ecossistema Python
A documentação não alerta (e ainda não - clique no link Docs no README deste repositório) contra o uso do pip programaticamente.
Não houve anúncio de que o pip de importação causaria esse dano em uma atualização do PATCH - esse anúncio veio para uma versão que ainda não foi lançada.
Essa mudança nem foi mencionada no Changelog
Não queremos substituir o pip ou os desenvolvedores do pip! Nós te amamos!
..mas não queremos que este tipo de coisa volte a acontecer!
..então queremos que sempre seja seguido!
Nós realmente gostaríamos de outro PATCH que desfaça essa grande mudança!
A necessidade de uma maneira programática de inspecionar um ambiente em um mundo pip>=10.0.0 é um tópico para outra discussão, mas o fato em questão é que nunca nos disseram que não deveríamos usar pip programaticamente no pip <=9 mundo, e houve uma mudança massiva e não anunciada, e realmente gostaríamos de vê-la revertida porque está afetando negativamente milhares de pessoas.

Obrigado novamente,
Rico

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@Miserlou

Dado o formato da string de versão, todos nós acreditamos que os mantenedores do pip estão seguindo o versionamento semântico

Como alguém que se opõe fortemente ao semver, você pode me informar em que formato minhas strings de versão devem estar para eliminar essa confusão? "Três números pontilhados" não implica "segue estritamente semver" para mim, então essa suposição é uma surpresa.

Em resposta a este comentário : Independentemente de o pip aderir ou não ao semver, ou prometer aderir a ele, o uso de um esquema de versionamento major.minor.micro ainda carrega uma promessa implícita de algum tipo de restrição em torno de micro lançamentos. Se um pino de liberação compatível como ~= 9.0.1 não for suficiente para proteger os usuários de quebras inesperadas na compatibilidade com versões anteriores, a única alternativa segura restante é a correspondência de versão simples . Se não houver intenção de oferecer suporte a nada além de correspondência de versão, o pip também pode mudar para um esquema de versão no estilo Chrome que possui apenas um componente monotonicamente crescente.

Edit: vejo que @dstufft já propôs avançar nessa direção adotando versões baseadas em data. Eu acho que seria uma peça infeliz de dano colateral para resultar deste incidente.

Então, sim, como usuários de um projeto de software dirigido por voluntários, precisamos equilibrar nossas expectativas com uma apreciação pela natureza do relacionamento usuário/mantenedor. Também está claro que este lançamento não foi feito para fazer import pip de repente começar a falhar. Por outro lado, porém, acho razoável que as pessoas fiquem frustradas com esse tipo de regressão acontecendo em uma micro versão, e lançar uma versão 9.0.3 que corrija o problema parece ser um remédio razoável.

Como aparte, posso reproduzir isso em um virtualenv (2 ou 3, não importa) com os seguintes passos:

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

Então, dentro do shell python:

>>> import requests
>>> import pip

Se as solicitações ainda não tiverem sido importadas, import pip será bem-sucedido.

quebras inesperadas na compatibilidade com versões anteriores

Por favor, indique-me onde import pip foi documentado como uma API estável que se enquadra nas promessas de compatibilidade com versões anteriores que fazemos? Eu gostaria de ter certeza de remover tal documentação, pois enfaticamente não apoiamos esse uso.

A menos que você seja da opinião de que absolutamente nada pode quebrar, mesmo usos não suportados e não testados. Nesse caso, você provavelmente deseja fixar == porque é totalmente desconhecido o que tudo o que você pode estar usando nesse ponto, e cada alteração potencialmente se torna uma alteração importante para alguém (obrigatório xkcd ).

pip é o gerenciador de pacotes do Python. Python é uma linguagem de programação. As pessoas precisam inspecionar seus ambientes programaticamente. 1+1=2.

Era perfeitamente razoável que as pessoas assumissem que essa era a maneira correta de fazer isso. Não havia - e ainda não há _ - nada na documentação dizendo _não_ para fazer isso. Como lembrete, existem mais de 700.000 aplicativos que chegaram a essa mesma conclusão ! Além disso - não há outra maneira de fazer isso!

Só porque algo não está documentado no ReadTheDocs não significa que seja proibido - todos nós encontramos e usamos projetos todos os dias que simplesmente fornecem código dessa maneira.

Se alguma coisa, o fato de que pip até _tem_ uma interface de linha de comando parece ser uma boa indicação de que ela pode ser usada como uma biblioteca, já que ela já possui um cliente Python!

Além disso, não estamos falando de APIs privadas com namespace _ , como é a convenção, ou mesmo qualquer método público específico, estamos falando apenas de _apenas chamar import_ que causa essa falha catastrófica.

Não havia - e ainda não há - nada na documentação dizendo para não fazer isso.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

Se você clicar no link "Documentos" de _este mesmo repositório_, você não chegará a essa página. Ninguém está referenciando mais recente. Seus próprios links para a documentação não estão vinculados ao mais recente. Não há como chegar a essa página. Tudo vai para estável, que não inclui essa seção.

@Miserlou Acho que essa nota é uma gentileza para as pessoas que de alguma forma pensam que deveriam importar os componentes internos de uma ferramenta de linha de comando apenas porque ela é implementada em Python e esses internos são importáveis.

Eu entendo que você tem uma interpretação diferente da interface pública de pip do que eu, os desenvolvedores e a maioria das pessoas que pensam em pip como um programa CLI, mas qual é o dano real disso? Basta fixar pip != 9.0.2 e pronto.

É óbvio que estamos todos na mesma página neste momento sobre o que é e o que não é parte da API pública suportada, e não há nada que possa ser feito agora para, de alguma forma, avisar retroativamente a todos.

Para ser honesto, os mantenedores do pip já afirmaram que, se o tempo permitir, eles tentarão corrigir esse problema, embora todos sejam incentivados a registrar uma solicitação de pull para acelerar as coisas.

Acho que, por enquanto, tudo o que podemos fazer é conscientizar as bibliotecas de terceiros sobre esse problema e apontá-las para esse problema. Bibliotecas de terceiros de longo prazo precisam corrigir esse problema de qualquer maneira e, esperançosamente, de uma maneira em que não import pip , mas chamem pip por meio da linha de comando (com subprocesso ou comandos python semelhantes).

Acredito que esta discussão dificilmente será produtiva nem há realmente algo adicional a ser dito. Há:

• Uma descrição adequada do problema.
• Possíveis soluções alternativas que alguém poderia empregar se se deparar com isso.
• Justificativa do motivo pelo qual não consideramos isso uma alteração importante de acordo com nossas diretrizes de compatibilidade com versões anteriores.
• Uma declaração de que tentarei encontrar tempo para corrigi-lo (embora sem promessas sobre isso).
• Um Call to Action que pode ser feito se alguém afetado por isso quiser tornar mais provável que exista um 9.0.3 com a correção.

Neste ponto, a discussão não serve para nenhum propósito real, exceto para frustrar ainda mais todos os envolvidos, então estou me afastando dessa questão por enquanto. Este problema será encerrado no lançamento de 10.0 ou 9.0.3. Se alguém se esforçar no Call To Action, será bem-vindo a abrir um pull request ou enviar um diff sobre esse problema.

Para tornar este mantra do-not-import-pip mais visível, que tal renomear o namespace para "_pip". Isso indica que o todo não é para uso público em um nível de nome.
Além disso, seria mais fácil dizer ao código de inspeção automática para não olhar para coisas que começam com sublinhado. Bem, este último também precisaria de mudanças no código de inspeção de envolvimento. Mas pelo menos há uma chance de automatizar por isso (por convenção) sem gerenciar listas negras.

Ok, a última coisa que eu juro - pip 10 já moveu todo o código relevante para pip._internal (não usamos _pip porque isso quebraria python -m pip , que é suportado).

Alguém pode verificar se https://github.com/pypa/pip/pull/5100 resolve isso para eles?

Raspe isso, acho que # 5100 está errado, você poderia verificar https://github.com/pypa/pip/pull/5101 , por favor.

@dstufft Posso confirmar, a correção em # 5101 resolve o problema para mim.

Obrigado @dstufft pelo seu tempo em resolver isso. Trabalharei com as equipes do Anaconda para comunicar esse problema e ajudá-los a deixar de importar pip.

Para o registro neste tópico, # 5101 resolveu meu problema também.

Idem, #5101 permite que a importação funcione dentro de nossa ferramenta. Emptor de advertência: eu não testei o pip corrigido nem nossa ferramenta extensivamente.

Isso deve ser corrigido em 9.0.3.

Obrigado pela resolução rápida, de alguém que nunca escreveu import pip na vida, mas foi consumidor de um pacote que escreveu. Depois de ler este tópico, parece que muitos aplicativos importaram o pip, sem saber, contra as práticas recomendadas, e muitos desenvolvedores e usuários são potencialmente afetados pela v9.0.2 e v10.

Eu segundo / terceiro / enésimo aviso de depreciação adequado sendo adicionado para tornar as coisas mais suaves. talvez até um post pypi.python.org?

Viva! Obrigado por isso!

Eu também adoraria um aviso de depreciação e, mais importante - instruções adequadas sobre como inspecionar ambientes python programaticamente em um mundo pip10! Claramente há uma necessidade disso, já que mais de 700.000 aplicativos foram afetados por esse bug.

pip list --format=json ?

Em primeiro lugar, obrigado a todos que contribuíram para o pip people, pois cobre totalmente todos os meus casos de uso com algumas opções e argumentos fáceis de usar.

Devido a esse "comportamento indefinido surpreendentemente amplamente adotado e útil" , precisamos fazer um piplib como libgit2 para git? Observe que a libgit2 não está compartilhando nenhum código com o git e é mantida por outro grupo do git's. E é bom para o ecossistema git. Talvez o piplib cubra alguns casos de uso interessantes que não esperávamos.

Aqui está uma história semelhante: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Suspeito que o que você propõe já esteja implementado nos pacotes existentes mencionados na documentação do pip , packaging , setuptools e distlib . Até onde posso dizer neste tópico, não há problema com uma lacuna na funcionalidade, mas algumas pessoas têm problemas com ferramentas que tentam importar e inspecionar todos os módulos e tratam falhas de importação como erros fatais.

Parece-me que essas ferramentas podem contornar esse problema envolvendo instruções de importação em um bloco try/except, mas isso também parece um precedente questionável a ser definido. Dado o lançamento do pip 9.0.3, no entanto, acho que provavelmente não vale a pena debater a questão da importação, a menos que o problema aconteça novamente no pip 10. De qualquer forma, contanto que os mantenedores não se esforcem para fazer import pip falhar, ou rejeitar sumariamente os patches que corrigem tais falhas, haveria um terreno comum para se apoiar.

@sruggier Os pacotes mencionados são todos bons, e WheelFile.install() também precisa de mais promoção. Mas o serviço de balcão único pip.main() fornecido é insubstituível com todos os itens acima. Ainda vale a pena tentar.

O mais importante é que espero que essas necessidades sejam atendidas por outro projeto, e o pip10 chegue sem problemas sem garantias extras. A depreciação e a minimização da base de código são os pontos principais para uma versão principal.

Detalhes concretos de implementação de um "software" de infraestrutura permanente são ridículos. Você não pode julgar os mantenedores pelo caso de abuso documentado e segurar a roda do pip.

Se você insistir em usar pip como lib, muitas suposições precisarão ser reconsideradas.

@drunkwcodes Só para ficar claro, pip.main() é o uso mais fácil de substituir - você só precisa usar subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

Além disso, a razão pela qual WheelFile.install() não é promovido é que o projeto wheel também declarou que eles não fornecem uma API visível ao usuário - originalmente mencionamos wheel nos documentos do pip, mas a removemos a pedido deles. A roda PEP é bastante clara sobre como você instala uma roda - não é difícil de implementar em um módulo de terceiros.

Eu aprecio o trabalho que todos vocês fazem no pip, e sei que não é fácil. Mas para constar:

Estou um pouco desapontado que as pessoas ainda não tenham se afastado do pip de importação. As pessoas atingidas por esse problema ainda precisarão se preparar para o pip 10

spaCy mudou de import pip . Mas algumas pessoas ainda estão usando o spaCy 1, que importou o pip --- e por razões óbvias, não fixou o pip em uma versão de patch. Se a mudança tivesse ocorrido na v10, nossas versões antigas não teriam sido afetadas. Acabamos de emitir um hotfix para resolver isso.

instrução adequada sobre como inspecionar programaticamente ambientes python em um mundo pip10

Qual é a posição do PyPA no distlib? O Pip obviamente está usando isso de alguma forma, mas também está usando o empacotamento, que o distlib pretende depreciar.

Se não houver uma posição oficial, pelo menos os pensamentos e opiniões atuais dos principais mantenedores do pip seriam muito apreciados. Se houver discussões relevantes sobre este tópico em outro lugar, um simples ponteiro para outras discussões é bom o suficiente para mim.

Eu não estou ciente de que o distlib depreca a embalagem. Ele menciona "distutils2/packaging", mas distutils2 era algo diferente.

Minha opinião pessoal é que tanto o distlib quanto o empacotamento são coisas perfeitamente razoáveis ​​para usar. Você deve avaliá-los para confirmar que atendem às suas necessidades, obviamente, assim como qualquer outra dependência em que você confia.

Talvez deprecates seja uma palavra muito forte então. A fonte do meu entendimento atual:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

Ah, essa é uma "embalagem" diferente - era o módulo stdlib proposto que pretendia substituir distutils. É completamente diferente do projeto PyPI packaging . Pode valer a pena pedir ao projeto distlib para esclarecer um pouco melhor essa distinção.

Pode valer a pena pedir ao projeto distlib para esclarecer um pouco melhor essa distinção.

Já fiz isso :) Veja: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Por favor, abra um novo problema para bugs relacionados.