Pregunta PyPI es lento. ¿Cómo ejecuto mi propio servidor?


Cuando un nuevo desarrollador se une al equipo, o Jenkins ejecuta una compilación completa, necesito crear un nuevo virtualenv. A menudo encuentro que establecer un virtualenv con Pip y un gran número (más de 10) de requisitos toma mucho tiempo para instalar todo desde PyPI. A menudo falla por completo con:

Downloading/unpacking Django==1.4.5 (from -r requirements.pip (line 1))
Exception:
Traceback (most recent call last):
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/basecommand.py", line 107, in main
    status = self.run(options, args)
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/commands/install.py", line 256, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/req.py", line 1018, in prepare_files
    self.unpack_url(url, location, self.is_download)
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/req.py", line 1142, in unpack_url
    retval = unpack_http_url(link, location, self.download_cache, self.download_dir)
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/download.py", line 463, in unpack_http_url
    download_hash = _download_url(resp, link, temp_location)
  File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.egg/pip/download.py", line 380, in _download_url
    chunk = resp.read(4096)
  File "/usr/lib64/python2.6/socket.py", line 353, in read
    data = self._sock.recv(left)
  File "/usr/lib64/python2.6/httplib.py", line 538, in read
    s = self.fp.read(amt)
  File "/usr/lib64/python2.6/socket.py", line 353, in read
    data = self._sock.recv(left)
timeout: timed out

Estoy al tanto de Pip --use-mirrors bandera, y a veces las personas de mi equipo han trabajado al usar --index-url http://f.pypi.python.org/simple (u otro espejo) hasta que tengan un espejo que responda de manera oportuna. Estamos en el Reino Unido, pero hay un espejo PyPI en Alemania, y no tenemos problemas para descargar datos de otros sitios.

Por lo tanto, estoy buscando formas de reflejar PyPI internamente para nuestro equipo.

Las opciones que he visto son:

  1. Ejecutando mi propia instancia PyPI. Está la implementación oficial de PyPI: Tienda de quesos así como varias implementaciones de terceros, tales como: djangopypi y pypiserver (ver nota al pie)

    El problema con este enfoque es que no estoy interesado en la funcionalidad completa de PyPI con la carga de archivos, solo quiero duplicar el contenido que proporciona.

  2. Ejecutando un espejo PyPI con pep381client o pipi-espejo.

    Parece que podría funcionar, pero requiere que mi espejo descargue todo desde PyPI primero. Configuré una instancia de prueba de pep381client, pero mi velocidad de descarga varía entre 5 Kb / sy 200 Kb / s (bits, no bytes). A menos que haya una copia del archivo completo de PyPI en algún lugar, me llevará semanas tener un espejo útil.

  3. Usando un proxy de round robin PyPI como yopypi.

    Esto es irrelevante ahora que http://pypi.python.org en sí mismo consiste en varios servidores geográficamente distintos.

  4. Copiar alrededor de un virtualenv entre desarrolladores, o alojar un carpeta de las dependencias del proyecto actual.

    Esto no escala: tenemos varios proyectos de Python diferentes cuyas dependencias cambian (lentamente) a lo largo del tiempo. Tan pronto como cambien las dependencias de cualquier proyecto, esta carpeta central debe actualizarse para agregar las nuevas dependencias. Sin embargo, copiar el virtualenv es peor que copiar los paquetes, ya que cualquier paquete Python con módulos C necesita ser compilado para el sistema objetivo. Nuestro equipo tiene usuarios de Linux y OS X.

    (Esto todavía se ve como la mejor opción de un grupo malo).

  5. Usando un proxy de caché de PyPI inteligente: collective.eggproxy

    Parece que sería una muy buena solución, pero la última versión en PyPI data de 2009 y discute mod_python.

¿Qué hacen otros equipos grandes de Python? ¿Cuál es la mejor solución para instalar rápidamente el mismo conjunto de paquetes de Python?

Notas al pie:


32
2018-03-21 19:11


origen


Respuestas:


¿Tienes un sistema de archivos compartido?

Porque usaría la configuración de caché de pip. Es bastante simple. Cree una carpeta llamada pip-cache en / mnt por ejemplo.

mkdir /mnt/pip-cache

Entonces cada desarrollador pondría la siguiente línea en su configuración de pip (unix = $ HOME / .pip / pip.conf, win =% HOME% \ pip \ pip.ini)

[global]
download-cache = /mnt/pip-cache

Todavía revisa PyPi, busca la última versión. Luego verifica si esa versión está en el caché. Si es así, lo instala desde allí. Si no, lo descarga. Lo almacena en la caché y lo instala. Entonces, cada paquete solo se descargaría una vez por cada versión nueva.


27
2018-03-21 22:44



Si bien no resuelve su problema PyPI, la entrega de virtualenvs construidos a los desarrolladores (o implementaciones) se puede hacer con Terrario.

Utilizar terrario empaquetar, comprimir y guardar virtualenvs. Puede almacenarlos localmente o incluso almacenarlos en S3. De la documentación en GitHub:

$ pip install terrarium
$ terrarium --target testenv --storage-dir /mnt/storage install requirements.txt

Después de crear un entorno nuevo, el terrario archivará y comprimirá el entorno y luego lo copiará en la ubicación especificada por el directorio de almacenamiento.

En instalaciones posteriores para el mismo conjunto de requisitos que especifican el mismo directorio de almacenamiento, terrario copiará y extraerá el archivo comprimido de / mnt / storage.

Para mostrar exactamente cómo terrario nombrará el archivo, puede ejecutar el siguiente comando:

$ terrarium key requirements.txt more_requirements.txt
x86_64-2.6-c33a239222ddb1f47fcff08f3ea1b5e1

9
2018-04-04 16:35



Recientemente instalé devpi en la configuración de Vagrant de mi equipo de desarrollo de modo que su caché de paquetes viva en el sistema de archivos del host. Esto permite que cada VM tenga su propio daemon devpi-server que usa como la url de índice para virtualenv / pip. Cuando las máquinas virtuales se destruyen y vuelven a aprovisionarse, no es necesario descargar los paquetes una y otra vez. Cada desarrollador los descarga una vez para construir su caché local mientras vivan en el sistema de archivos del host.

También tenemos un índice interno de PyPi para nuestros paquetes privados que actualmente es solo un directorio al que da servicio Apache. En última instancia, voy a convertir eso en un servidor proxy devpi también para que nuestro servidor de compilación también mantenga un caché de paquetes para nuestras dependencias de Python, además de alojar nuestras bibliotecas privadas. Esto creará un búfer adicional entre nuestro entorno de desarrollo, las implementaciones de producción y el PyPi público.

Esta parece ser la solución más sólida que he encontrado para estos requisitos hasta la fecha.


7
2018-01-28 20:51



Eche un vistazo a David Wolever's pip2pi. Puede simplemente configurar un trabajo cron para mantener un espejo de los paquetes que necesita de toda la empresa o equipo, y luego señalar sus puntos hacia su espejo interno.


3
2018-04-25 18:40



Configure su servidor local y luego modifique el archivo de hosts de la computadora local para sobrescribir la URL real en lugar de apuntar al servidor local omitiendo así el DNS estándar. Luego, elimine la línea en el archivo de host si ya terminó.

O supongo que podrías encontrar la URL en pip y modificar eso.


-1
2018-03-21 22:29