Ответ 1
Это может быть связано с изменением доменов PyPI в 2018 году.
Убедитесь, что ваш брандмауэр/прокси-сервер разрешает доступ к/из:
- pypi.org
- files.pythonhosted.org
Таким образом, вы можете попробовать что-то вроде:
$ python -m pip
install--trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org [--proxy...] [--user]<packagename>
Пожалуйста, смотрите $ pip help install для --user опции --user (опустите, если в virtualenv).
Опция --trusted-host самом деле не обходит SSL/TLS, но позволяет пометить хост как надежный, когда (и только когда) у него нет действительного (или какого-либо) HTTPS. Это не должно иметь большого значения для PiPY, потому что pypi.org (ранее pypi.python.org) действительно использует HTTPS, и перед ним есть CDN, который всегда обеспечивает требование рукопожатия TLSv1.2 независимо от параметров подключаемого клиента pip. Но если у вас были свои локальные зеркала pypi.org с доступом только по HTTP, тогда --trusted-host может быть --trusted-host. Да, и если вы находитесь за прокси-сервером, также обязательно укажите: --proxy [user:[email protected]]proxyserver:port
Некоторые корпоративные прокси-серверы могут даже пойти на замену сертификатов HTTPS-соединений на лету. И если ваши системные часы не синхронизированы, это также может нарушить процесс проверки SSL.
Если брандмауэр/прокси/часы не являются проблемой, то проверьте SSL-сертификаты, используемые в рукопожатии SSL в pip. На самом деле, вы можете просто получить текущий cacert.pem (пакет Mozilla CA из curl) и попробовать его, используя параметр pip --cert:
$ pip --cert ~/cacert.pem install --user <packagename>
где аргумент--cert- системный путь к альтернативному--certCA в формате PEM. (относительно опции --user, пожалуйста, смотрите ниже).
Или можно создать пользовательскую конфигурацию ~/.pip/pip.conf и указать опцию на действительный системный сертификат (или ваш cacert.pem) в качестве обходного пути, например:
[Глобальный]
cert =/etc/pki/tls/external-roots/ca_bundle.pem
(или другой файл pem)
Можно даже вручную заменить оригинальный cacert.pem, найденный в pip, на ваш верный пакет CA (например, если ваш pip очень старый). Более ранние версии пипсов, как известно, имели запасной вариант между pip/_vendor/запросы/cacert.pem и системными хранилищами, такими как /etc/ssl/certs/ca-certificates.crt или /etc/pki/tls/certs/ca-bundle.crt в случае проблемы с сертификатом, но в последнем пипе это уже не так, так как кажется, что он полагается исключительно на pip/_vendor/certifi/cacert.pem
По сути, пакет pip использует requests использующие urllib3 который, помимо прочего, проверяет сертификаты SSL; и все они поставляются (продаются) в рамках pip вместе с пакетом certifi (также включенным, начиная с pip 9.0.2), который предоставляет текущий пакет CA (файл cacert.pem), необходимый для проверки TLS. Сам по себе запрос использует urllib3 и certifi для внутреннего использования, а до 9.0.2 pip использовал cacert.pem из запросов или системы. Все это означает, что собственно обновление pip может помочь исправить ошибку CERTIFICATE_VERIFY_FAILED, особенно если ОС и pip были развернуты давно:
-
ОП использовал анаконду, чтобы они могли попробовать:
$ conda update pip- потому что могут возникнуть проблемы, если conda иpipиспользуются вместе в одной среде. Если обновление версии pip недоступно, они могут попробовать:$ conda config --add channels conda-forge; conda update pip
В качестве альтернативы можно использовать только conda для непосредственной установки/управления пакетами Python: это инструмент, полностью отделенный от pip, но обеспечивающий аналогичные функции с точки зрения управления пакетами и venv. Его пакеты приходят не из PyPI, а из собственных репозиториев Anaconda. Проблема в том, что если вы смешаете оба и запускаете conda послеpip, первый может перезаписать и разорвать пакеты (и их зависимости), установленные через pip, и сделать все это непригодным для использования. Поэтому рекомендуется использовать только один или другой, или, если необходимо, использовать только pip после conda (и не conda после pip), и только в изолированных условиях conda. -
На обычных установках Linux Python без conda:
Если вы используете версию pip, поставляемую дистрибутивом ОС, то используйте обновления, предоставляемые поставщиком, для общесистемного обновления pip:$ sudo apt-get install python-pipили:$ sudo yum install python27-pip
Некоторые обновления могут быть недоступны, поскольку дистрибутивы обычно отстают от PyPI. В этом случае можно обновить pip на уровне пользователя (прямо в директории $ HOME) или внутри virtualenv, например:$ python -m pip install --user --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org --upgrade pip
(опустить--userесли в virtualenv)
Переключатель--userобновит pip только для текущего пользователя (у вас дома ~/.local/lib/), а не для всей ОС, что является хорошей практикой во избежание вмешательства в системные пакеты python. Он включен по умолчанию в пипсах, распространяемых в последних версиях Ubuntu/Fedora. Знайте, как решить ImportError, если вы не используете эту опцию и случайно перезаписали системный пип на уровне ОС.
В качестве альтернативы (также на уровне пользователя) вы можете попробовать:$ curl -LO https://bootstrap.pypa.io/get-pip.py && python get-pip.py --user
PyPA сценарий содержит оболочку, которая извлекает .pem SSL сверток из pip._vendor.certifi.
В противном случае, если все еще нет, попробуйте запустить pip с -vvv чтобы добавить многословность к выходным данным и проверить, есть ли еще один SSLError вызванный версией протокола оповещения tlsv1.