Pip: Обновление до pip 10: это проект с установленным distutils, и поэтому мы не можем точно определить, какие файлы ему принадлежат, что приведет только к частичному удалению.

Созданный на 16 апр. 2018  ·  41Комментарии  ·  Источник: pypa/pip

  • Версия пункта: 10.0.0
  • Версия Python: 2.7
  • Операционная система: Amazon Linux AMI, оптимизированный для ECS 2017.09.i

Описание:

Я пытаюсь установить docker-py, это обычная часть рабочего процесса по настройке инфраструктуры, и мы запускаем его довольно долго. Для некоторых пакетов я получаю следующую ошибку:

Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

Все работает, как ожидалось, с pip 9.0.2. Что-то изменилось? Что я могу сделать, чтобы это исправить? (кроме закрепления версии пункта до 9.0.2 или 9.0.3)

Что я пробежал:

Первая попытка установки с pip 10

# /usr/local/bin/pip2 install docker-py
Collecting docker-py
  Using cached docker_py-1.10.6-py2.py3-none-any.whl
Requirement already satisfied: six>=1.4.0 in /usr/local/lib/python2.7/site-packages (from docker-py) (1.11.0)
Requirement already satisfied: backports.ssl-match-hostname>=3.5; python_version < "3.5" in /usr/local/lib/python2.7/site-packages (from docker-py) (3.5.0.1)
Requirement already satisfied: ipaddress>=1.0.16; python_version < "3.3" in /usr/local/lib/python2.7/site-packages (from docker-py) (1.0.22)
Requirement already satisfied: websocket-client>=0.32.0 in /usr/local/lib/python2.7/site-packages (from docker-py) (0.47.0)
Collecting requests!=2.11.0,>=2.5.2 (from docker-py)
  Using cached requests-2.18.4-py2.py3-none-any.whl
Collecting docker-pycreds>=0.2.1 (from docker-py)
  Using cached docker_pycreds-0.2.2-py2.py3-none-any.whl
Requirement already satisfied: idna<2.7,>=2.5 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py) (2.6)
Requirement already satisfied: urllib3<1.23,>=1.21.1 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py) (1.22)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py) (2018.1.18)
Collecting chardet<3.1.0,>=3.0.2 (from requests!=2.11.0,>=2.5.2->docker-py)
  Using cached chardet-3.0.4-py2.py3-none-any.whl
Installing collected packages: chardet, requests, docker-pycreds, docker-py
  Found existing installation: chardet 2.0.1
Cannot uninstall 'chardet'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

Понизился до пункта 9.0.3, а затем получил следующее:

# /usr/local/bin/pip2 install docker-py
Collecting docker-py
  Cache entry deserialization failed, entry ignored
  Cache entry deserialization failed, entry ignored
  Downloading docker_py-1.10.6-py2.py3-none-any.whl (50kB)
    100% |████████████████████████████████| 51kB 4.8MB/s
Requirement already satisfied: six>=1.4.0 in /usr/local/lib/python2.7/site-packages (from docker-py)
Requirement already satisfied: backports.ssl-match-hostname>=3.5; python_version < "3.5" in /usr/local/lib/python2.7/site-packages (from docker-py)
Requirement already satisfied: ipaddress>=1.0.16; python_version < "3.3" in /usr/local/lib/python2.7/site-packages (from docker-py)
Requirement already satisfied: websocket-client>=0.32.0 in /usr/local/lib/python2.7/site-packages (from docker-py)
Collecting requests!=2.11.0,>=2.5.2 (from docker-py)
  Cache entry deserialization failed, entry ignored
  Cache entry deserialization failed, entry ignored
  Downloading requests-2.18.4-py2.py3-none-any.whl (88kB)
    100% |████████████████████████████████| 92kB 8.2MB/s
Collecting docker-pycreds>=0.2.1 (from docker-py)
  Cache entry deserialization failed, entry ignored
  Cache entry deserialization failed, entry ignored
  Downloading docker_pycreds-0.2.2-py2.py3-none-any.whl
Requirement already satisfied: idna<2.7,>=2.5 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py)
Requirement already satisfied: urllib3<1.23,>=1.21.1 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python2.7/site-packages (from requests!=2.11.0,>=2.5.2->docker-py)
Collecting chardet<3.1.0,>=3.0.2 (from requests!=2.11.0,>=2.5.2->docker-py)
  Cache entry deserialization failed, entry ignored
  Cache entry deserialization failed, entry ignored
  Downloading chardet-3.0.4-py2.py3-none-any.whl (133kB)
    100% |████████████████████████████████| 143kB 7.7MB/s
Installing collected packages: chardet, requests, docker-pycreds, docker-py
  Found existing installation: chardet 2.0.1
    DEPRECATION: Uninstalling a distutils installed project (chardet) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling chardet-2.0.1:
      Successfully uninstalled chardet-2.0.1
  Found existing installation: requests 1.2.3
    Uninstalling requests-1.2.3:
      Successfully uninstalled requests-1.2.3
Successfully installed chardet-3.0.4 docker-py-1.10.6 docker-pycreds-0.2.2 requests-2.18.4
You are using pip version 9.0.3, however version 10.0.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Я также заметил проблемы с установкой awscli, он жалуется, что некоторые пакеты не установлены. (Однако их установка устраняет проблему).

Если я попытаюсь принудительно переустановить awscli, например, я получаю ту же ошибку для PyYAML:
It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

Самый полезный комментарий

Я выполнил следующие шаги и решил эту проблему

  1. Уменьшенная версия:
    pip install --upgrade --force-reinstall pip==9.0.3
  2. Пытался переустановить пакет:
    pip install xxx --disable-pip-version-check
  3. Наконец, восстановите последнюю версию для pip:
    pip install --upgrade pip

Все 41 Комментарий

Se # 4805 и # 3389 для истории. По сути, pip не может правильно удалить пакеты, установленные "чистыми" distutils, потому что distutils не записывает достаточно метаданных для нас. Ранее мы удалили метаданные установки, так что похоже, что мы выполнили установку, но нам пришлось оставить файлы. Это вызывает проблемы. Начиная с пункта 8, мы пытаемся прекратить это делать, потому что это вызывает проблемы, но наша первоначальная попытка была отменена, потому что в то время это затронуло слишком много людей. С pip 10 мы наконец перестали пытаться удалить пакеты distutils и теперь сообщаем пользователю о проблеме, как вы видите здесь.

По сути, если вы (или какая-то инфраструктура, которую вы используете) установили пакет с помощью distutils, вам нужно управлять (и в частности) удалить его «с помощью distutils». К сожалению, distutils не включает команду удаления, поэтому «удалить с помощью distutils» означает удалить пакет вручную.

@pfmoore Спасибо за быстрый ответ!

Это довольно неудобно, потому что большинство пакетов устанавливаются как зависимости, и мы не управляем этим сами. Будет интересно автоматизировать удаление.

Я вижу, что есть некоторые движения к обновлению только пакетов без их предварительного удаления. Было бы здорово, если бы это со временем произошло.

Мы могли бы закрыть этот вопрос, поскольку он широко обсуждается где-то еще. Спасибо!

Попробуйте удалить пакет вручную из "site-packages". Это отлично работает!

Я, кажется, обхожу эту проблему, предоставляя версию pip с помощью команды
pip install -I == 9.0.3 -r requirements.txt

Я выполнил следующие шаги и решил эту проблему

  1. Уменьшенная версия:
    pip install --upgrade --force-reinstall pip==9.0.3
  2. Пытался переустановить пакет:
    pip install xxx --disable-pip-version-check
  3. Наконец, восстановите последнюю версию для pip:
    pip install --upgrade pip

Кажется, это решает проблему для меня: https://github.com/blockstack/blockstack-core/issues/504

В исходном случае выше это будет:

pip install docker-py --ignore-installed PyYAML

Не знаю, кто ты, но я люблю тебя.

Итак, @pfmoore, что бы вы порекомендовали команде, которая автоматизирует установку своих пакетов? Мы настроили наш сервер с помощью terraform, поэтому мы автоматически вызываем pip install для smart-open и boto3, а затем у нас есть numpy, scipy, boto, sklearn и datadog в файле requirements.txt. Мы получаем ошибку distutils для urllib3 при нескольких установках (потому что это установлено smart-open). Установка работает, когда я использую --ignore-installed urllib3 , но есть ли более правильный способ сделать это?

Кроме того, есть ли шанс, что distutils добавит функцию удаления или дополнительные метаданные? Вы, ребята, говорили об этом с этой командой?

@ ruby-is-pretty-cool У меня нет реального мнения по этому поводу. Вы говорите о urllib3 «потому что это установлено smart-open», но я не вижу в smart-open ничего, что декларировало бы зависимость от urllib3, поэтому я не знаю, что вы имеете в виду. Если smart-open каким-то образом устанавливает urllib3 таким образом, что вызывает эту проблему, это звучит как проблема smart-open.

Кроме того, есть ли шанс, что distutils добавит функцию удаления или дополнительные метаданные? Вы, ребята, говорили об этом с этой командой?

Не то чтобы я об этом знал, и мы не говорили с ними об этом. Я сомневаюсь, что они это сделают, поскольку в наши дни distutils на самом деле не реализует новые функции (но не стесняйтесь спрашивать, хотите ли вы). Официальная документация по упаковке в любом случае не рекомендует использовать distutils напрямую, поэтому, если в проектах это используется, им действительно нужно управлять последствиями.

Просто попробовал установить smart-open. Это зависит от запросов, которые, в свою очередь, зависят от urllib3. Это правильно устанавливается с помощью pip, когда я выполняю установку в virtualenv. Вы делаете эту установку в системной среде? В каком случае вы видите (и пытаетесь обновить), что в системе установлен urllib3? Если это так, применяется обычный совет «не используйте pip в системных пакетах» - используйте virtualenv или, если вам нужно установить в свою системную среду, используйте пакеты дистрибутива.

Я новичок в упаковке Python, но мне кажется, что пакет virtualenv или пакет дистрибутива решат нашу проблему - мне придется изучить их подробнее. Спасибо за помощь!

Это безумие. Установки ломаются из-за религиозных убеждений. если какая-то запись в setup.py какого-либо пакета касается urllib3, то нет способа указать ему игнорировать его. В нашем случае мы должны обновить urllib3, потому что в Ubuntu 14 установленная версия pip (v1.5.x) отказывается устанавливать пакеты с URL-адресов https.

Дело в том, что никто не стал бы обновлять «системные» пакеты, если бы они не перестали работать. В проекте ядра Linux такое поведение «нарушает пространство пользователя», и Торвальдс плохо на это реагирует. Невероятные питоны воспринимают это так естественно.

По крайней мере, вы должны предупреждать людей в сообщениях pip с чем-то вроде "эта версия pip откажется работать, если это означает обновление системных пакетов, сделайте это и сделайте то". Используйте pip версии 9.x, если вы работаете со старыми установщиками или старыми системы ". или похожие.

Хорошо, я не обратил внимания, так как мой все еще в шланге, но моя точка зрения более проста.
Вся причина агрессивного обновления пользовательской среды заключалась в следующем: ATT&T и Беркли все еще пытались понять, кто построил мусорное ведро, говорите ... И если у вас есть дерьмо для установки на aha1542, вы можете отказаться от туалета, который был дозирован из-за лицензирования; и так как это тоже появилось недавно, они в первую очередь объясняют, почему мы делаем это дерьмо; ради ХРИСТА, это иметь выбор И сотрудничать. Я до сих пор как-то сбит с толку, почему slackeware и путь * bsd ушли в глубину, но в любом случае, даже в двух лагерях, один будет управлять другим, мне наскучит ядро, вернусь к 2.x, 16+ экранам, (Мне еще предстоит переопределить драйвер промикса в меню, но я отвлекся, и теперь вернемся к своему обычному расписанию, черт возьми, мы не можем получить .app, так что это дерьмо работает день. (Разумеется, отвинчивания.)

Я согласен с @pabloa - это продолжается вечно, обычная установка CentOS 7 не может установить docker-compose из-за этого.

И да, @JohnBDonner , этот маленький флаг сэкономил мне МНОГО времени. СПАСИБО

Начальная ошибка

«Невозможно удалить 'pywin32'. Это проект, установленный distutils, и поэтому мы не можем точно определить, какие файлы ему принадлежат, что приведет только к частичному удалению»

Как туда попасть?

На моем компьютере установлен pywin32 == 221, и теперь я пытаюсь удалить его обновленную версию (pywin == 224), я получил ссылку на его ".whl", и у меня возникли проблемы с их установкой. поскольку я получил следующую ошибку: «Невозможно удалить 'pywin32'. Это установленный проект distutils, и поэтому мы не можем точно определить, какие файлы ему принадлежат, что приведет только к частичному удалению. " . Я использую Windows 10 64bit, использую py3.4 32bit.

Причина, по которой я это делаю?

потому что кажется, что "win32.client" на моем компьютере имеет только "оптимизировать" файл python с расширением .pyo. Я узнал об этом, когда получаю сообщение об ошибке компиляции, в котором говорится, что у меня нет модуля «Диспетчерская», доступного для «из win32com.client import Dispatch». Благодарю, если кто-нибудь может мне помочь в этом.

ТЫ С УМА СОШЕЛ, БРО??

Нет, но спасибо за случайное оскорбление. Делать это в свободное время так полезно: smile:

Это не предназначалось для решения проблемы. Он был призван объяснить, почему все обстоит так, как есть, и почему pip не может решить проблему. То, что люди грустят по поводу ситуации, не меняет ее.

Можно ли изменить пакет установщика, используемый disyutils, таким образом, чтобы
он включает необходимые метаданные?
В четверг, 22 ноября 2018 г., в 12:56 Пол Мур [email protected]
написал:

Это не предназначалось для решения проблемы. Это должно было объяснить, почему
все так, как есть, и почему pip не может решить проблему. Просто
потому что люди грустят по поводу ситуации, это не меняет.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441095536 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADrjCZvIpDr4X1sxcSZe3rRH7MBnn7Tsks5uxuVagaJpZM4TWMU4
.

>

Ник Артман
+1 (330) 558-1230

Не знаю, над distutils не работаю. Но даже если бы это было так, зачем людям в наши дни использовать distutils? Этот поток посвящен пакетам, которые уже были установлены с помощью distutils. Решение для них уже упоминалось ранее в этой теме .

@AddoSolutions само изменение, о котором вы просите, называется setuptools

Я нахожусь в этой теме потому, что часто работаю с ванилью.
Ящики CentOS 7 и специально устанавливаем на них docker compose. CentOS
поставляется с пипсом, и проблема в том, что я получаю эти ошибки, как описано
выше.

Лично я не особо пользуюсь Python, я просто использую docker compose и
sshuttle на нем. Я лично понятия не имею, в чем разница между инструментами настройки
и distutils, я предполагаю, что питон CentOS в основном установлен
используя yum при установке?

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

Мысли?

Примечание: я полностью понимаю, что могу вникнуть в разницу и, вероятно, сделаю это
но прошу это для будущих пользователей, и это тоже благодарение, и я хочу
Турция :)
В чт, 22 ноября 2018 г., в 13:19 Ронни Пфанншмидт [email protected]
написал:

@AddoSolutions https://github.com/AddoSolutions то самое изменение, которое вы просите
для называется setuptools

-
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441099032 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADrjCTBfoKjBuYdceDeBM0bunByQ2bxJks5uxuq2gaJpZM4TWMU4
.

>

Ник Артман
+1 (330) 558-1230

что касается обновлений пакета yum - это в значительной степени работа дистрибутива - и он этого не делал, но и сами пакеты в некоторых случаях

Когда дело доходит до корпоративных дистрибутивов - все так сильно устарело - выясните это с вашим поставщиком - апстримы с открытым исходным кодом не имеют над этим власти и никогда не должны нести бремя поддержки по вашему выбору в корпоративных дистрибутивах - так что обратитесь к своему поставщику

Попался. Таким образом, пакет pip в этом случае будет поддерживаться CentOS.
group, а НЕ группой pip?
В чт, 22 ноября 2018 г., в 17:38 Ronny Pfannschmidt [email protected]
написал:

с обновлениями пакета yum - это в значительной степени работа
дистрибутив - и он этого не делал, но и пакеты
сами в некоторых случаях

когда дело доходит до корпоративных дистрибутивов - все до боли устарело -
выясните это с вашим поставщиком - апстримы с открытым исходным кодом не имеют власти над
это и никогда не должны нести бремя поддержки за ваш выбор в
корпоративные дистрибутивы - обращайтесь к своему поставщику

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441129627 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADrjCZAQ-ZBmpkm7izyKkE0WymSoT6M1ks5uxyd2gaJpZM4TWMU4
.

>

Ник Артман
+1 (330) 558-1230

@AddoSolutions проблема здесь не в pip, а в других пакетах - pip просто остановил претензии и отказался от поддержки действительно плохих вещей, и теперь все разваливается на плохих участников, таких как корпоративные дистрибутивы, поэтому вам нужно разобраться в пакете с точки зрения предприятия дистрибутивы и с вашим поставщиком

просто к сведению - вам, вероятно, будет предложено использовать pip из системы (управляемой поставщиком), а не случайную последнюю версию

Я получал эту ошибку для wxPython

Невозможно удалить wxPython. Это установленный проект distutils, и поэтому мы не можем точно определить, какие файлы ему принадлежат, что привело бы только к частичному удалению.

Он был расположен не в sitepackages а в distpackages (что имеет смысл), но удаление файла из папки было неправильным.

Оказывается, я установил его через apt , поэтому выполнение apt remove --autoremove python-wxgtk3.0 удалило пакет из моей системы.

Этого "не наша проблема, кто-то другой исправит" следует ожидать от pip. Программа даже не претендует на управление конфликтами пакетов. Я получил это сообщение как часть возможного развертывания контейнеров во многих системах.

Спасибо за тех из вас, кто предоставил обходные пути. Я изменил порядок - «pip install docker» до «pip install --upgrade pip» - на этот раз работал. Надеюсь, это не вызовет проблем (таких как повреждение данных) в будущем.

Я считаю, что мы должны использовать виртуальные среды, чтобы защитить себя от странностей в наших средах ... однако я смог пока обойти это, добавив флаг --user :

pip3 install -r requirements.txt --user

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

Вы также можете попробовать работать с точной версией временной зависимости, которая была установлена ​​вашей средой / distutils поскольку она может быть совместимой. В моем примере Pipenv разрешит временную зависимость PyYAML awscli==1.15.85 и apache-airflow==1.10.1 до 3.13, но в системе уже установлено 3.11. Глядя на заявленные зависимости на моей локальной машине разработки, 3.11 подойдет и для того, и для другого:

$ 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]

Простой pipenv install PyYAML==3.11 закрепит PyYAML на 3.11 и сделает оба пакета счастливыми:

$ 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]

Мой Pipfile / Pipfile.lock впоследствии полностью устанавливается на Ubuntu 14.04LTS с использованием pipenv install --deploy --system .

Я также проверил, что PyYAML==3.11 устанавливается через python3-yaml 3.11-3build1, и это прямая зависимость от cloud-init 18.4-0ubuntu1 ~ 16.04.2, который мы широко используем при запуске на EC2. И 18.04 LTS, и 18.10 поставляются с PyYAML 3.12, только 19.04 будет поставляться с PyYAML , который на сегодняшний день является последней версией.

При этом любой ценой избегайте системных зависимостей и проблем с окружающей средой. Используйте pipenv и / или virtualenv .

Я выполнил следующие шаги и решил эту проблему:

  1. Уменьшенная версия,
    pip install --upgrade --force-reinstall pip==9.0.3
  2. Пытался переустановить пакет
    pip install xxx --disable-pip-version-check
  3. Наконец, восстановите последнюю версию для pip
    pip install --upgrade pip

У меня это сработало. Но вызывает ли обновление pip после этого какие-либо проблемы с установленными пакетами?

@ s-eswar Пока мы не обнаружили проблем с пакетом, но, возможно, одна ситуация, когда вы используете старшую версию пакета установки pip, затем используйте более низкую версию, переустановите или проверьте, может возникнуть проблема зависимости. Я предлагаю всегда использовать более раннюю версию. Например, пункт 9.0.3.

@ s-eswar Пока мы не обнаружили проблем с пакетами, но, возможно, одна ситуация, когда при использовании высокой версии пакета установки pip и использовании более низкой версии, переустановка или проверка может возникнуть проблема зависимости. Я предлагаю всегда использовать более раннюю версию. Например, пункт 9.0.3.

@ wangxf1987, но при использовании ML-библиотек с той же конфигурацией мы не получаем ошибок при обновлении / использовании более ранней версии.

@ s-eswar Я не уверен, что библиотеки ML работают с более ранней версией. Я использую pip = 9.0.3, работает с последней версией Kubernetes. Следует проверить файл требований, нужна ли последняя версия пакета или тестирование в среде разработки.

Начиная с пункта 8, мы пытаемся прекратить это делать, потому что это вызывает проблемы, но наша первоначальная попытка была отменена, потому что в то время это затронуло слишком много людей. С pip 10 мы наконец перестали пытаться удалить пакеты distutils и теперь сообщаем пользователю о проблеме, как вы видите здесь.

Я считаю, что часть «теперь мы сообщаем о проблеме пользователю» называется «переложить свой технологический долг на кого-то другого». Хочу поблагодарить всех за то, что привели меня к фиаско. Тем более, что я не разработчик Python и понятия не имею, как это исправить. У меня сейчас много часов над этой проблемой. Ура!

Удалить пакет Dist и ЗАПУСТИТЬ

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

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

Удаление папки из distutils работает

при обновлении до более новой версии он должен решить проблемы, но pip вызывает проблемы, ирония судьбы.

Решение состоит в том, чтобы удалить его вручную, поэтому перейдите в ... / anaconda3 / lib / python3. * / Site-packages / и удалите все файлы и папки пакета.

@ramonamis sudo pip install --ignore-installed PyYAML

Это успешно улучшило его для меня.

Это также сработало для imutils:

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

Я выполнил следующие шаги и решил эту проблему

  1. Уменьшенная версия:
    pip install --upgrade --force-reinstall pip==9.0.3
  2. Пытался переустановить пакет:
    pip install xxx --disable-pip-version-check
  3. Наконец, восстановите последнюю версию для pip:
    pip install --upgrade pip

у меня работает , Спасибо!

Я выполнил следующие шаги и решил эту проблему

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`

это плохое решение. Теперь я ничего не могу сделать.

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

Я сейчас блокирую эту тему. Первый комментарий

Была ли эта страница полезной?
0 / 5 - 0 рейтинги