Se # 4805 e # 3389 para a história. Basicamente, o pip não pode desinstalar corretamente os pacotes instalados por distutils "puros", porque distutils não registra metadados suficientes para nós fazermos isso. Anteriormente, removemos os metadados de instalação, de modo que parece que fizemos a instalação, mas tivemos que deixar os arquivos para trás. Isso causa problemas. Desde o pip 8, temos tentado parar de fazer isso, porque é uma causa de problemas, mas nossa tentativa inicial foi revertida porque afetou muitas pessoas na época. Com o pip 10, finalmente paramos de tentar desinstalar os pacotes distutils e agora relatamos o problema ao usuário como você vê aqui.

Basicamente, se você (ou alguma infraestrutura que você usa) instalou um pacote usando distutils, você precisa gerenciar (e em particular) desinstalá-lo "usando distutils". Infelizmente distutils não inclui um comando de desinstalação, então "desinstalar usando distutils" significa remover manualmente o pacote.

@pfmoore Obrigado pela resposta rápida!

Isso é bastante inconveniente porque a maioria dos pacotes vêm instalados como dependências e não gerenciamos nós mesmos. Será interessante automatizar a remoção.

Vejo que há um movimento para atualizar apenas os pacotes, sem desinstalá-los primeiro. Seria ótimo se isso eventualmente acontecesse.

Poderíamos encerrar esse problema, pois ele é amplamente discutido em outro lugar. Obrigado!

Tente remover o pacote manualmente de "pacotes do site". Isso funciona perfeitamente!

Parece que estou contornando esse problema fornecendo a versão do pip com o comando
pip install -I == 9.0.3 -r requisitos.txt

Usei seguir os passos e resolvi este problema

1. Versão reduzida:
   pip install --upgrade --force-reinstall pip==9.0.3
2. Tentei reinstalar o pacote:
   pip install xxx --disable-pip-version-check
3. Por fim, recupere a versão mais recente do pip:
   pip install --upgrade pip

Isso parece resolver o problema para mim: https://github.com/blockstack/blockstack-core/issues/504

No caso original acima, seria:

pip install docker-py --ignore-installed PyYAML

Não sei quem você é, mas eu te amo.

Então, @pfmoore o que você recomendaria para uma equipe que automatiza suas instalações de pip? Configuramos nosso servidor usando terraform, então chamamos automaticamente pip install para smart-open e boto3 e então temos numpy, scipy, boto, sklearn e datadog em um requirements.txt. Obtemos o erro distutils para urllib3 para várias instalações (porque o smart-open o instalou). As instalações funcionam quando eu uso --ignore-installed urllib3 , mas existe uma maneira mais adequada de fazer isso?

Além disso, há alguma chance de que distutils adicione um recurso de desinstalação ou mais metadados? Vocês já conversaram com aquela equipe sobre isso?

@ ruby-is-pretty-cool Não tenho uma opinião real sobre isso. Você diz de urllib3 "porque o smart-open o instalou", mas não vejo nada no smart-open que declare uma dependência de urllib3, então não sei o que você quer dizer com isso. Se o smart-open está de alguma forma instalando o urllib3 de uma forma que desencadeia esse problema, isso soa como um problema de smart-open.

Além disso, há alguma chance de que distutils adicione um recurso de desinstalação ou mais metadados? Vocês já conversaram com aquela equipe sobre isso?

Não que eu saiba, e não, não falamos com eles sobre isso. Eu duvido que sim, já que distutils não implementa novos recursos atualmente (mas fique à vontade para perguntar se você quiser). A documentação oficial do pacote não recomenda o uso de distutils diretamente, então, se os projetos estão fazendo isso, é realmente com eles o gerenciamento das implicações.

Acabei de tentar instalar o smart-open. Depende de solicitações, que por sua vez dependem de urllib3. Isso é instalado corretamente pelo pip quando faço a instalação em um virtualenv. Você está fazendo esta instalação em um ambiente de sistema? Nesse caso, você está vendo (e tentando atualizar) o sistema urllib3 instalado? Nesse caso, o conselho normal "não use pip em pacotes de sistema" se aplica - use um virtualenv ou se você precisar instalar em seu ambiente de sistema, use pacotes de distro.

Eu sou muito novo no empacotamento Python, mas tenho a sensação de que um pacote virtualenv ou distro resolverá nosso problema - terei que examiná-los mais. Obrigado pela ajuda!

Isso é uma loucura. As instalações estão sendo quebradas por causa de algumas crenças religiosas. se alguma entrada setup.py de algum pacote tocar urllib3, então não há como dizer a ele para ignorá-lo. Em nosso caso, devemos atualizar o urllib3 porque no Ubuntu 14 a versão instalada do pip (v1.5.x) se recusa a instalar pacotes de URLs https.

O ponto é que ninguém atualizaria os pacotes do "sistema" se eles não parassem de funcionar. No projeto do kernel do Linux, esse comportamento está "quebrando o espaço do usuário" e o Torvalds não reage bem a isso. É incrível que as pessoas python o aceitem bem naturalmente.

Pelo menos você deve avisar as pessoas em mensagens pip com algo como "esta versão do pip se recusará a funcionar se significar atualizar os pacotes do sistema, faça isso e faça aquilo. Use o pip versão 9.x se estiver trabalhando com instaladores antigos ou antigos sistemas. " ou similar.

Ok, eu não estava prestando atenção porque o meu ainda está maluco, mas meu ponto é mais simples.
A razão inteira para apenas atualizar o userland agressivamente foi: ATT & T e berkley ainda estavam tentando descobrir quem construiu a lata de lixo, persay ... E se você tivesse a merda para instalar no aha1542, poderia se livrar de uma joalete que foi dosada devido ao licenciamento; e como isso também aconteceu recentemente, eles explicam por que fazemos essa merda em primeiro lugar; pelo amor de Cristo, é ter as escolhas E cooperar. Ainda estou de alguma forma perplexo porque o slackeware e o caminho * bsd foram para o fundo do poço, mas de qualquer forma, mesmo em dois campos, um dirigirá o outro, ficaria entediado com o kernel, voltar para 2.x, 16+ telas, (Ainda não encontrei o driver promix no menu, mas estou divagando, e agora de volta à minha programação regular, WTF não podemos obter um .app, então essa merda funciona dia. (De errar, é claro.)

Eu concordo com @pabloa - Isso está acontecendo há muito tempo, uma instalação vanilla do CentOS 7 não pode instalar docker-compose por causa disso.

E sim, @JohnBDonner , aquela bandeirinha acabou de me economizar MUITO tempo. OBRIGADA

Erro Inicial

"Não é possível desinstalar 'pywin32'. É um projeto instalado do distutils e, portanto, não podemos determinar com precisão quais arquivos pertencem a ele, o que levaria a apenas uma desinstalação parcial"

Como eu chego lá?

Eu tenho o pywin32 == 221 instalado em minha máquina, e agora estou tentando desinstalar uma versão de atualização dele (pywin == 224), ganhei o link para seu ".whl" e estou enfrentando desafios para instalá-los como recebi o seguinte erro "Não é possível desinstalar 'pywin32'. É um projeto instalado distutils e, portanto, não podemos determinar com precisão quais arquivos pertencem a ele, o que levaria a apenas uma desinstalação parcial. " . Estou no Windows 10 de 64 bits, usando py3.4 de 32 bits.

Razão pela qual estou fazendo isso?

é porque parece que "win32.client" na minha máquina só tem a extensão de arquivo "otimizar" arquivo python ".pyo". Eu descobri isso quando recebo um erro de compilação dizendo que não tenho o módulo "Dispatch" disponível para "from win32com.client import Dispatch". Agradeço se alguém puder me ajudar nisso.

VOCÊ É LOUCO MANO??

Não, mas obrigado pelo abuso aleatório. Isso torna isso no meu tempo livre muito gratificante: sorria:

Não pretendia resolver o problema. A intenção era explicar por que as coisas são do jeito que são e por que pip não consegue resolver o problema. Só porque as pessoas estão tristes com a situação não a altera.

É possível mudar o pacote de instalação usado por disyutils de modo que
inclui os metadados necessários?
Na quinta-feira, 22 de novembro de 2018 às 12h56, Paul Moore [email protected]
escreveu:

Não pretendia resolver o problema. A intenção era explicar por que
as coisas são como são e por que pip não consegue resolver o problema. Somente
porque as pessoas estão tristes com a situação não a altera.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441095536 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADrjCZvIpDr4X1sxcSZe3rRH7MBnn7Tsks5uxuVagaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

Não sei, não trabalho com destutils. Mas mesmo se fosse, por que as pessoas usariam distutils hoje em dia? Este tópico é sobre pacotes que já foram instalados usando distutils. A solução para aqueles já foi

@AddoSolutions a própria mudança que você pede é chamada de setuptools

Então, estou neste tópico porque costumo trabalhar com baunilha
CentOS 7 e, especificamente, instale o docker compose nelas. CentOS
vem estoque com pip e o problema é que recebo esses erros conforme descrito
acima de.

Pessoalmente, não sou muito de um usuário de Python, apenas uso docker compose e
sshuttle sobre ele. Eu pessoalmente não tenho ideia da diferença entre ferramentas de configuração
e distutils, suponho que o CentOS python está basicamente instalado
usando o yum ao instalar?

Duas coisas com isso: o pacote yum pode ser atualizado de forma que inclua
os metadados corretos? Alternativamente, poderia ao obter este erro, poderia
a mensagem fornece informações mais úteis sobre o que fazer? Gosto em vez do
mensagem relativamente criptografada sobre distutils (novamente para pessoas como eu usando
pip eu nem sei o que é isso) poderia dizer algo como "o caminho
que o pip foi instalado não é recomendado. Recomendamos a desinstalação por
fazer xe reinstalar usando x ”. Eu sinto que isso seria
reduzir significativamente o número de pessoas com problemas com isso.

Pensamentos?

Nota: eu sei perfeitamente que poderia cavar na diferença, e provavelmente irei,
mas pedir isso para futuros usuários também é ação de graças e eu quero
Turquia :)
Na quinta-feira, 22 de novembro de 2018 às 13h19 Ronny Pfannschmidt [email protected]
escreveu:

@AddoSolutions https://github.com/AddoSolutions a própria mudança que você pede
pois é chamado de ferramentas de configuração

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441099032 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADrjCTBfoKjBuYdceDeBM0bunByQ2bxJks5uxuq2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

escrever as atualizações do pacote yum - isso é basicamente o trabalho da distribuição - e não tem feito isso, mas nem os próprios pacotes em alguns casos

quando se trata de distros empresariais - as coisas estão tão desatualizadas - resolva isso com seu fornecedor - os upstreams de código aberto não têm poder sobre isso e nunca deveriam ter que arcar com a carga de suporte por sua escolha em distros empresariais - então vá para o seu fornecedor

Peguei vocês. Portanto, o pacote pip, neste caso, seria mantido pelo CentOS
grupo, NÃO pelo grupo pip?
Na quinta-feira, 22 de novembro de 2018 às 17:38 Ronny Pfannschmidt [email protected]
escreveu:

wrt as atualizações do pacote yum - isso é basicamente o trabalho do
distribuição - e não tem feito isso, mas nem os pacotes
em alguns casos

quando se trata de distros empresariais - as coisas estão tão desatualizadas -
resolva isso com seu fornecedor - upstreams de código aberto não têm poder sobre
que e nunca deve ter que arcar com o fardo de suporte para sua escolha em
distribuições corporativas - vá até o seu fornecedor

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441129627 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADrjCZAQ-ZBmpkm7izyKkE0WymSoT6M1ks5uxyd2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

@AddoSolutions o problema não é pip, mas outros pacotes - pip simplesmente parou de fingir e abandonou o suporte para coisas realmente ruins, e agora as coisas desmoronam em agentes mal-intencionados, como distros corporativos - então você tem que resolver o pacote em termos de empresa distros e com o seu fornecedor

apenas um FYI - provavelmente você será instruído a usar pip do sistema (gerenciado pelo fornecedor) e não uma versão mais recente aleatória

Eu estava recebendo este erro de wxPython

Não é possível desinstalar 'wxPython'. É um projeto instalado com distutils e, portanto, não podemos determinar com precisão quais arquivos pertencem a ele, o que levaria a apenas uma desinstalação parcial.

Ele não estava localizado em sitepackages mas em distpackages (o que faz sentido), mas não pareceu certo deletar o arquivo da pasta.

Acontece que eu tinha instalado por meio de apt , então fazer apt remove --autoremove python-wxgtk3.0 removeu o pacote do meu sistema.

Esse "problema não é nosso, alguém conserta" é de se esperar do pip. O software nem mesmo finge gerenciar conflitos de pacotes. Recebi esta mensagem como parte de uma implantação ansible de contêineres em muitos sistemas.

Obrigado por aqueles de vocês que forneceram soluções alternativas. Eu mudei a ordem - "pip install docker" antes de "pip install --upgrade pip" - funcionou desta vez. Esperançosamente, isso não causará problemas (como corrupção de dados) no futuro.

Minha leitura disso é que deveríamos estar usando ambientes virtuais para nos proteger de estranheza em nossos ambientes ... no entanto, fui capaz de superar isso por enquanto adicionando a sinalização --user :

pip3 install -r requirements.txt --user

https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption -user

Você também pode tentar trabalhar com a versão exata da dependência temporária que foi instalada pelo seu ambiente / distutils , pois pode ser compatível. No meu exemplo, o Pipenv resolverá a dependência transitória de PyYAML de awscli==1.15.85 e apache-airflow==1.10.1 para 3.13, mas o sistema já tem 3.11 instalado. Olhando para as dependências declaradas em minha máquina de desenvolvimento local, 3.11 seria adequado para ambos:

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.13]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.13]

Um simples pipenv install PyYAML==3.11 fixará PyYAML em 3.11 e deixará ambos os pacotes felizes:

$ pipenv install PyYAML==3.11
Installing PyYAML==3.11…
...
Locking [packages] dependencies…
✔ Success!

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.11]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.11]

Meu Pipfile / Pipfile.lock posteriormente é instalado de forma limpa no Ubuntu 14.04LTS usando pipenv install --deploy --system .

Eu também verifiquei e PyYAML==3.11 está instalado por meio de python3-yaml 3.11-3build1 e é uma dependência direta de cloud-init 18.4-0ubuntu1 ~ 16.04.2, que usamos extensivamente enquanto executamos no EC2. Tanto o 18.04 LTS quanto o 18.10 vêm com o PyYAML 3.12, apenas 19.04 virá com o PyYAML , que por acaso é a versão mais recente a partir de hoje.

Dito isso, evite dependências do sistema e problemas ambientais a todo custo. Use pipenv e / ou virtualenv .

Usei os seguintes passos e resolvi este problema:

1. Versão reduzida,
   pip install --upgrade --force-reinstall pip==9.0.3
2. Tentei reinstalar o pacote
   pip install xxx --disable-pip-version-check
3. Por fim, recupere a versão mais recente do pip
   pip install --upgrade pip

Isto funcionou bem para mim. Mas atualizar o pip depois disso causa problemas nos pacotes instalados ??

@ s-eswar Até agora, não encontramos problemas com o pacote, mas talvez uma situação em que se usar a versão alta do pacote de instalação do pip, use a versão inferior, re-instalar ou verificar pode ocorrer problema de dependência. Eu sugiro que sempre use a versão inferior. Por exemplo, pip 9.0.3.

@ s-eswar Até agora, não encontramos problemas para pacotes, mas talvez uma situação em que se usar a versão alta do pacote de instalação do pip e usar a versão inferior re-instalar ou verificar possa ocorrer problema de dependência. Eu sugiro que sempre use a versão inferior. Por exemplo, pip 9.0.3.

@ wangxf1987 mas por usar bibliotecas de ML com a mesma configuração, não recebemos erros em relação à atualização / uso de uma versão anterior.

@ s-eswar Não tenho certeza se as bibliotecas de ML funcionam em versões anteriores. Usar pip = 9.0.3 funciona com a versão mais recente do Kubernetes. Deve-se verificar o arquivo de requisitos se precisa da versão mais recente do pip ou teste no env dev.

Desde o pip 8, temos tentado parar de fazer isso, porque é uma causa de problemas, mas nossa tentativa inicial foi revertida porque afetou muitas pessoas na época. Com o pip 10, finalmente paramos de tentar desinstalar os pacotes distutils e agora relatamos o problema ao usuário como você vê aqui.

Acredito que a parte "agora relatamos o problema ao usuário" é chamada de "empurrando sua dívida tecnológica para outra pessoa". Gostaria de agradecer a todos por me trazerem para o fiasco. Especialmente porque não sou um desenvolvedor de Python e não tenho ideia de como consertar isso. Chego a gastar horas com esse problema agora. Viva!

Remover Pacote Dist e RUN

sudo rm -rf /usr/lib/python3/dist-packages/yaml

sudo rm -rf /usr/lib/python3/dist-packages/PyYAML-*

Remover pasta de trabalhos distutils

atualizando para uma versão mais recente, deve resolver os problemas, mas pip introduz problemas que ironia.

A solução é desinstalá-lo manualmente, então vá para ... / anaconda3 / lib / python3. * / Site-packages / e exclua todos os arquivos e pastas do pacote

@ramonamis sudo pip install --ignore-installed PyYAML

Isso o atualizou com sucesso para mim.

Isso também funcionou para imutils:

pip install --upgrade imutils --ignore-installed imutils

Usei seguir os passos e resolvi este problema

1. Versão reduzida:
   pip install --upgrade --force-reinstall pip==9.0.3
2. Tentei reinstalar o pacote:
   pip install xxx --disable-pip-version-check
3. Por fim, recupere a versão mais recente do pip:
   pip install --upgrade pip

funciona para mim ， Obrigado!

Usei seguir os passos e resolvi este problema

1. Reduced version:
   `pip install --upgrade --force-reinstall pip==9.0.3`

2. Tried to re-install package:
   `pip install xxx --disable-pip-version-check`

3. At last, recover the latest version for pip:
   `pip install --upgrade pip`

esta é uma solução ruim. Não posso fazer nada agora.

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-pip : Depends: python-pip-whl (= 9.0.1-2.3~ubuntu1) but 9.0.1-2.3~ubuntu1.18.04.1 is to be installed
               Recommends: python3-dev (>= 3.2) but it is not going to be installed
               Recommends: python3-setuptools but it is not going to be installed
               Recommends: python3-wheel but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Success

Estou bloqueando este tópico agora. O comentário inicial de @pfmoore cobre tudo aqui. O resto deste tópico foi divulgado em solicitações de suporte ou abusos direcionados aos mantenedores.