web-dev-qa-db-fra.com

PyPI est lent. Comment exécuter mon propre serveur?

Lorsqu'un nouveau développeur rejoint l'équipe ou que Jenkins exécute une version complète, je dois créer un nouveau virtualenv. Je trouve souvent que la configuration d'un virtualenv avec Pip et un grand nombre (plus de 10) d'exigences prend beaucoup de temps pour tout installer à partir de PyPI. Souvent, il échoue complètement avec:

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

Je connais le pip de --use-mirrors flag, et parfois les membres de mon équipe ont travaillé en utilisant --index-url http://f.pypi.python.org/simple (ou un autre miroir) jusqu'à ce qu'ils aient un miroir qui réponde en temps opportun. Nous sommes au Royaume-Uni, mais il y a un miroir PyPI en Allemagne, et nous n'avons aucun problème pour télécharger des données à partir d'autres sites.

Je cherche donc des façons de refléter PyPI en interne pour notre équipe.

Les options que j'ai examinées sont les suivantes:

  1. Exécuter ma propre instance PyPI. Il y a l'implémentation officielle de PyPI: CheeseShop ainsi que plusieurs implémentations tierces, telles que: djangopypi et pypiserver (voir note de bas de page)

    Le problème avec cette approche est que je ne suis pas intéressé par la fonctionnalité PyPI complète avec le téléchargement de fichiers, je veux juste refléter le contenu qu'il fournit.

  2. Exécution d'un miroir PyPI avec pep381client ou pypi-mirror .

    Il semble que cela puisse fonctionner, mais il faut que mon miroir télécharge tout depuis PyPI en premier. J'ai mis en place une instance de test de pep381client, mais ma vitesse de téléchargement varie entre 5 Kb/s et 200 Kb/s (bits, pas octets) Sauf s'il y a une copie de l'archive PyPI complète quelque part, il me faudra des semaines pour avoir un miroir utile.

  3. Utilisation d'un proxy à tour de rôle PyPI tel que yopypi .

    Cela n'est plus pertinent maintenant que http://pypi.python.org lui-même se compose de plusieurs serveurs géographiquement distincts .

  4. Copie autour d'un virtualenv entre développeurs, ou hébergement d'un dossier des dépendances du projet en cours .

    Cela ne change pas d'échelle: nous avons plusieurs différents projets Python dont les dépendances changent (lentement) au fil du temps. Dès que les dépendances de tout projet changent, ce dossier central doit être mis à jour pour ajouter le nouveau Cependant, la copie de virtualenv est pire que la copie des packages, car tous les packages Python avec modules C doivent être compilés pour le système cible. Notre équipe a des utilisateurs Linux et OS X.

    (Cela ressemble toujours à la meilleure option d'un mauvais groupe.)

  5. Utilisation d'un proxy de mise en cache PyPI intelligent: collective.eggproxy

    Cela semble être une très bonne solution, mais la dernière version sur PyPI est datée de 2009 et discute mod_python.

Que font les autres grandes équipes Python? Quelle est la meilleure solution pour installer rapidement le même ensemble de packages python?

Notes de bas de page:

39
Wilfred Hughes

Avez-vous un système de fichiers partagé?

Parce que j'utiliserais le paramètre de cache de pip. C'est assez simple. Créez un dossier appelé pip-cache dans/mnt par exemple.

mkdir /mnt/pip-cache

Ensuite, chaque développeur mettrait la ligne suivante dans sa configuration pip (unix = $ HOME/.pip/pip.conf, win =% HOME%\pip\pip.ini)

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

Il vérifie toujours PyPi, recherche la dernière version. Vérifie ensuite si cette version est dans le cache. Si c'est le cas, il l'installe à partir de là. Sinon, il le télécharge. Le stocke dans le cache et l'installe. Ainsi, chaque package ne serait téléchargé qu'une seule fois par nouvelle version.

29
aychedee

Bien qu'il ne résout pas votre problème PyPI, la remise de virtualenvs construits aux développeurs (ou déploiements) peut être effectuée avec Terrarium.

Utilisez terrarium pour emballer, compresser et enregistrer virtualenvs. Vous pouvez les stocker localement ou même les stocker sur S . De la documentation sur GitHub:

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

Après avoir créé un nouvel environnement, Terrarium archivera et compressera l'environnement, puis le copiera à l'emplacement spécifié par stockage-dir.

Lors des installations suivantes pour le même ensemble d'exigences qui spécifient le même répertoire de stockage, terrarium copiera et extraira l'archive compressée de/mnt/storage.

Pour afficher exactement comment terrarium nommera l'archive, vous pouvez exécuter la commande suivante:

$ terrarium key requirements.txt more_requirements.txt
x86_64-2.6-c33a239222ddb1f47fcff08f3ea1b5e1
9
Kyle Kelley

J'ai récemment installé devpi dans la configuration Vagrant de mon équipe de développement de telle sorte que le cache de son package réside sur le système de fichiers de l'hôte. Cela permet à chaque VM d'avoir son propre démon devpi-server qu'il utilise comme index-url pour virtualenv/pip. Lorsque les VM sont détruites et réapprovisionnées, les packages n'ont pas besoin d'être Chaque développeur les télécharge une fois pour créer leur cache local aussi longtemps qu'ils vivent sur le système de fichiers de l'hôte.

Nous avons également un index PyPi interne pour nos packages privés qui n'est actuellement qu'un répertoire servi par Apache. En fin de compte, je vais également convertir cela en serveur proxy devpi afin que notre serveur de génération maintienne également un cache de package pour nos dépendances Python en plus d'héberger nos bibliothèques privées. Cela créera un tampon supplémentaire entre notre environnement de développement, les déploiements de production et le PyPi public.

Cela semble être la solution la plus robuste que j'ai trouvée à ces exigences à ce jour.

8
Joe Holloway

Jetez un œil au pip2pi de David Wolever . Vous pouvez simplement configurer un travail cron pour conserver un miroir à l'échelle de l'entreprise ou de l'équipe des packages dont vous avez besoin, puis pointer vos pépins vers votre miroir interne.

3
gotgenes