Solución:
Puede estar relacionado con el cambio de dominios PyPI de 2018.
Asegúrese de que su firewall / proxy permita el acceso a / desde:
- pypi.org
- files.pythonhosted.org
Entonces podrías probar algo como:
$ python -m pip
install–trusted-host files.pythonhosted.org –trusted-host pypi.org –trusted-host pypi.python.org [–proxy …] [–user]<packagename>
Por favor mira $ pip help install Para el --user descripción de la opción (omitir si en un virtualenv).
los --trusted-host La opción no omite SSL / TLS, pero permite marcar el host como confiable cuando (y solo cuando) no tiene HTTPS válido (o ninguno). Realmente no debería importar con PiPY porque pypi.org (anteriormente pypi.python.org) lo hace use HTTPS y hay CDN frente a él que siempre impone el requisito de protocolo de enlace TLSv1.2 independientemente de las opciones de conexión del cliente pip .. Pero si tuviera sus propios espejos locales de pypi.org con acceso solo HTTP, entonces --trusted-host podría ser útil. Ah, y si está detrás de un proxy, asegúrese de especificar también: --proxy [user:[email protected]]proxyserver:port
Algunos servidores proxy corporativos pueden incluso llegar a reemplazar los certificados de las conexiones HTTPS sobre la marcha. Y si el reloj de su sistema no está sincronizado, también podría interrumpir el proceso de verificación SSL.
Si el firewall / proxy / reloj no es un problema, verifique los certificados SSL que se utilizan en el protocolo de enlace SSL de pip. De hecho, podría obtener un cacert.pem actual (paquete CA de Mozilla de curl) y probarlo usando la opción pip --cert:
$ pip --cert ~/cacert.pem install --user <packagename>dónde
--certEl argumento es la ruta del sistema a su paquete CA alternativo en formato PEM. (con respecto a la opción –user, consulte a continuación).
O bien, es posible crear una configuración personalizada ~ / .pip / pip.conf y apuntar la opción a un certificado de sistema válido (o su cacert.pem) como solución alternativa, por ejemplo:
[global]
cert = /etc/pki/tls/external-roots/ca_bundle.pem(u otro archivo pem)
Incluso es posible reemplazar manualmente el cacert.pem original que se encuentra en pip con su paquete de CA de confianza (si su pip es muy antiguo, por ejemplo). Las versiones anteriores de pip sabían que podían recurrir a pip / _vendor / request / cacert.pem y las tiendas del sistema como /etc/ssl/certs/ca-certificates.crt o /etc/pki/tls/certs/ca-bundle.crt en caso de problemas de certificación, pero en pip reciente ya no es el caso, ya que parece depender únicamente de pip / _vendor / certifi / cacert.pem
Básicamente, el paquete pip usa requests que usa urllib3 que, entre otras cosas, verifica los certificados SSL; y todos ellos se envían (vende) dentro de pip, junto con el certifi paquete (también incluido, desde pip 9.0.2) que proporciona el paquete de CA actual (archivo cacert.pem) necesario para la verificación de TLS. Las solicitudes en sí usan urllib3 y certifi internamente, y antes de 9.0.2, pip usaba cacert.pem de las solicitudes o del sistema. Lo que todo esto significa es que la actualización de pip puede ayudar a corregir el error CERTIFICATE_VERIFY_FAILED, especialmente si el sistema operativo y el pip se implementaron hace mucho tiempo:
-
El OP usó anaconda, por lo que pudieron intentar:
$ conda update pip– porque pueden surgir problemas si conda ypipambos se utilizan juntos en el mismo entorno. Si no hay una actualización de la versión de pip disponible, podrían intentar:
$ conda config --add channels conda-forge; conda update pipAlternativamente, es posible usar conda solo para instalar / administrar directamente paquetes de Python: es una herramienta completamente separada de pip, pero proporciona características similares en términos de administración de paquetes y venv. Sus paquetes no provienen de PyPI, sino de los propios repositorios de anaconda. El problema es que si mezclas ambos y ejecutas conda después
pip, el primero puede sobrescribir y romper paquetes (y sus dependencias) instalados a través de pip y dejarlo todo inutilizable. Por eso se recomienda solo usa uno u otro, o, si es necesario, use solo pip después conda (y no conda después de pip), y solo en entornos conda aislados. -
En instalaciones normales de Linux Python sin conda:
Si está utilizando una versión de pip proporcionada por la distribución de su sistema operativo, utilice las actualizaciones proporcionadas por el proveedor para una actualización de pip en todo el sistema:
$ sudo apt-get install python-pipo:$ sudo yum install python27-pipEs posible que algunas actualizaciones no estén disponibles fácilmente porque las distribuciones generalmente se quedan atrás de PyPI. En este caso, es posible actualizar pip en su nivel de usuario (justo en tu $ INICIO dir), o dentro de un virtualenv, como:
$ python -m pip install --user --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org --upgrade pip(omitir
--usersi en un virtualenv)
los--userswitch actualizará pip solo para el usuario actual (en su hogar ~ / .local / lib /) en lugar de para todo el sistema operativo, lo cual es una buena práctica para evitar interferir con los paquetes de Python del sistema. Está habilitado por defecto en un pip distribuido en versiones recientes de Ubuntu / Fedora. Tenga en cuenta cómo resolver ImportError si no usa esta opción y sobrescribe el pip del sistema a nivel del sistema operativo.
Alternativamente (también a nivel de usuario) puede intentar:
$ curl -LO https://bootstrap.pypa.io/get-pip.py && python get-pip.py --userEl script PyPA contiene un contenedor que extrae el paquete SSL .pem de pip._vendor.certifi.
De lo contrario, si sigue sin funcionar, intente ejecutar pip con -vvv opción para agregar verbosidad a la salida y verificar si ahora hay otra SSLError causado por la versión del protocolo de alerta tlsv1.
Mi camino es una simplificación de la respuesta de @Alex C:
python -m pip install --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org --upgrade pip