Подтвердить что ты не робот

PyPI медленный. Как запустить собственный сервер?

Когда новый разработчик присоединяется к команде, или Jenkins запускает полную сборку, мне нужно создать новый virtualenv. Я часто нахожу, что настройка virtualenv с помощью Pip и большое количество (более 10) требований занимает очень много времени, чтобы установить все из PyPI. Часто это происходит не полностью:

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

Я знаю флаг Pip --use-mirrors, и иногда люди в моей команде работали с помощью --index-url http://f.pypi.python.org/simple (или другого зеркала), пока у них не появится зеркало, отвечающее своевременно. Мы находимся в Великобритании, но в Германии есть зеркало PyPI, и у нас нет проблем с загрузкой данных с других сайтов.

Итак, я ищу способы отразить PyPI внутри нашей команды.

Параметры, на которые я смотрел:

  • Запуск моего собственного экземпляра PyPI. Там была официальная реализация PyPI: CheeseShop, а также несколько сторонних реализаций, таких как: djangopypi и pypiserver (см. сноску)

    Проблема с этим подходом заключается в том, что я не заинтересован в полной функциональности PyPI с загрузкой файла, я просто хочу отразить контент, который он предоставляет.

  • Запуск зеркала PyPI с pep381client или pypi-mirror.

    Похоже, что это может сработать, но для моего зеркала нужно сначала загрузить все из PyPI. Я установил тестовый экземпляр pep381client, но скорость загрузки варьируется от 5 Кбит/с до 200 Кбит/с (бит, а не байтов). Если там где-то копия полного архива PyPI, мне понадобится несколько недель, чтобы иметь полезное зеркало.

  • Использование прокси-сервера round-robin PyPI, такого как yopypi.

    Теперь это не имеет значения, когда http://pypi.python.org состоит из несколько географически разных серверов.

  • Копирование виртуального пространства между разработчиками или размещение папки текущих зависимостей проекта.

    Это не масштабируется: у нас есть несколько различных проектов Python, зависимости которых изменяются (медленно) со временем. Как только изменения любого проекта будут изменены, эта центральная папка должна быть обновлена, чтобы добавить новые зависимости. Копирование виртуального файла хуже, чем копирование пакетов, хотя, поскольку любые пакеты Python с модулями C необходимо скомпилировать для целевой системы. Наша команда имеет пользователей Linux и OS X.

    (Это по-прежнему выглядит как лучший вариант плохой группы.)

  • Использование интеллектуального кэширующего прокси-сервера PyPI: collective.eggproxy

    Кажется, это было бы очень хорошим решением, но последняя версия PyPI датируется 2009 годом и обсуждает mod_python.

Что делают другие большие команды Python? Какое лучшее решение для быстрой установки одного и того же набора пакетов python?

Сноска:

4b9b3361

Ответ 1

Есть ли у вас общая файловая система?

Потому что я бы использовал настройку кэша пика. Это довольно просто. Например, создайте папку с именем pip-cache в /mnt.

mkdir /mnt/pip-cache

Затем каждый разработчик помещает следующую строку в свою конфигурацию pip (unix = $HOME/.pip/pip.conf, win =% HOME%\pip\pip.ini)

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

Он по-прежнему проверяет PyPi, ищет последнюю версию. Затем проверяет, находится ли эта версия в кеше. Если это так, он будет устанавливать его оттуда. Если он не загружает его. Хранит его в кеше и устанавливает его. Таким образом, каждый пакет будет загружен только один раз за новую версию.

Ответ 2

В то время как это не решает проблему PyPI, передача встроенных virtualenvs разработчикам (или развертываниям) может выполняться с помощью Terrarium.

Используйте Terrarium, чтобы упаковать, сжать и сохранить virtualenvs. Вы можете хранить их локально или даже хранить их на S3. Из документации по GitHub:

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

После создания новой среды террариум будет архивировать и сжимать среду, а затем скопировать ее в место, указанное в файле-хранилище.

При последующих установках для того же набора требований, которые указывают один и тот же каталог-хранилище, террариум будет копировать и извлекать сжатый архив из /mnt/storage.

Чтобы отобразить, как именно террариум будет называть архив, вы можете запустить следующую команду:

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

Ответ 3

Недавно я установил devpi в мою конфигурацию Vagrant команды разработки, так что ее кеш-пакет живет в файловой системе хоста, Это позволяет каждой виртуальной машине иметь собственный демон devpi-сервера, который он использует в качестве индекса-url для virtualenv/pip. Когда виртуальные машины уничтожаются и повторно просматриваются, пакеты не нужно загружать снова и снова. Каждый разработчик загружает их один раз для создания своего локального кеша до тех пор, пока они живут в файловой системе хоста.

У нас также есть внутренний индекс PyPi для наших частных пакетов, который в настоящее время является только каталогом, обслуживаемым Apache. В конечном счете, я собираюсь преобразовать это в прокси-сервер devpi, так что наш сервер сборки также будет поддерживать кеш-память для наших зависимостей Python в дополнение к размещению наших частных библиотек. Это создаст дополнительный буфер между нашей средой разработки, производственными развертываниями и публичным PyPi.

Это, кажется, самое надежное решение, которое я нашел для этих требований на сегодняшний день.

Ответ 4

Взгляните на Дэвида Волевера pip2pi. Вы можете просто настроить задание cron, чтобы сохранить зеркало в пакетах вашей компании или команды в нужном вам пакете, а затем указать свои точки на свое внутреннее зеркало.

Ответ 5

Настройте локальный сервер, затем измените файл хостов локального компьютера, чтобы перезаписать фактический URL, чтобы вместо этого указать на локальный сервер, тем самым пропустив стандартный DNS. Затем удалите строку в файле хоста, если вы закончили.

Или я предполагаю, что вы можете найти URL-адрес в pip и изменить его.