установка пакетов python без интернета и использование исходного кода as.смола.gz и.whl

мы пытаемся установить пару пакетов Python без интернета.

For ex : python-keystoneclient

для этого у нас есть пакеты, загруженные из https://pypi.python.org/pypi/python-keystoneclient/1.7.1 и сохранил его на сервере.

однако при установке tar.gz и .WHL пакеты, установка ищет зависимые пакеты для установки в первую очередь. Поскольку на сервере нет подключения к интернету, он получает сбой.

для ex : Для python-keystoneclient у нас есть следующие зависимые пакеты

stevedore (>=1.5.0)
six (>=1.9.0)
requests (>=2.5.2)
PrettyTable (<0.8,>=0.7)
oslo.utils (>=2.0.0)
oslo.serialization (>=1.4.0)
oslo.i18n (>=1.5.0)
oslo.config (>=2.3.0)
netaddr (!=0.7.16,>=0.7.12)
debtcollector (>=0.3.0)
iso8601 (>=0.1.9)
Babel (>=1.3)
argparse
pbr (<2.0,>=1.6)

когда я пытаюсь установить пакеты один за другим из приведенного выше списка, снова ищем вложенную зависимость .

есть ли способ, мы могли бы перечислить все зависимые пакеты для установки модуля python, такого как python-keystoneclient.

16
openstack pip python

3 ответов

вот как я справляюсь с этим делом:

на машине, где у меня есть доступ к интернету:

mkdir keystone-deps
pip download python-keystoneclient -d "/home/aviuser/keystone-deps"
tar cvfz keystone-deps.tgz keystone-deps

затем переместите файл tar на конечный компьютер, который не имеет доступа в Интернет, и выполните следующие действия:

tar xvfz keystone-deps.tgz
cd keystone-deps
pip install python_keystoneclient-2.3.1-py2.py3-none-any.whl -f ./ --no-index
30

у нас аналогичная ситуация на работе, где производственные машины не имеют доступа к Интернету; поэтому все должно управляться в автономном режиме и вне хоста.

вот что я пробовал с различным количеством успеха:

  1. basket это небольшая утилита, которую вы запускаете на своем хосте, подключенном к интернету. Вместо того, чтобы пытаться установить пакет, он вместо этого загрузит его, и все остальное, что требуется для установки в справочник. Затем этот каталог перемещается на целевой компьютер. Плюсы: очень прост и удобен в использовании, нет головных болей сервера; нет портов для настройки. Минусы: нет никаких реальных showstoppers, но самый большой из них является то, что он не уважает любую версию закрепления вы можете иметь; он всегда будет загружать последнюю версию пакета.

  2. запустите локальный сервер pypi. Используется pypiserver и devpi. pypiserver очень прост в установке и настройке; devpi требуется немного больше finagling. Они оба делают то же самое - действуют как прокси/кэш для реального pypi и как локальный сервер pypi для любых домашних пакетов. localshop это новый, которого не было, когда я смотрел, у него также есть та же идея. Итак, как это работает, ваша машина с ограниченным доступом в интернет будет подключаться к этим серверам, затем они подключаются к Интернету, чтобы они могли кэшировать и прокси-сервер фактического репозитория.

проблема с второй подход заключается в том, что хотя вы получите максимальную совместимость и доступ ко всему репозиторию пакетов Python, вы все равно должны убедиться, что все зависимости установлены на вашей целевой машины (например, все заголовки на базе драйверов и утилит). Кроме того, эти решения не обслуживают репозитории, отличные от PyPI (например, пакеты, размещенные на github).

мы получили очень далеко со вторым вариантом, хотя, поэтому я бы определенно рекомендовал он.

в конце концов, устав от проблем совместимости и библиотек, мы перенесли весь цирк серверов в коммерчески поддерживаемые контейнеры docker.

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

мы заменили репозитории pypi локальным сервером изображений docker.

6

pipdeptree - утилита командной строки для отображения пакетов python, установленных в virtualenv в виде дерева зависимостей. Просто использовать его: https://github.com/naiquevin/pipdeptree

0