Каков рекомендуемый способ распространения пользовательской среды Python? - PullRequest
Новая
       56

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

0 голосов
/ 25 сентября 2019

Проблема

Я хочу распространять некоторые пользовательские пакеты Python на вычислительные узлы.Путь установки не совпадает с путем сборки, поэтому пути не могут быть жестко запрограммированы.Процесс установки должен быть не более сложным, чем source /path/to/MyOrgCode/setup.sh, и в идеале не должен требовать загрузки или переустановки всего.Я вижу несколько потенциальных способов сделать это, каждый из которых, кажется, имеет серьезные недостатки.

Некоторые предпосылки для конкретного примера

Сообщество физиков высоких энергий использует инструмент под названием CVMFS для распределения скомпилированных исполняемых файлов, библиотек и файлов данных по узлам вычислительных кластеров.,Обычно вы компилируете свой код на машине с той же архитектурой, что и узлы, а затем публикуете ее в центральном хранилище.Поэтому я мог бы построить свой код в /home/user/MyOrg, который после публикации появится на вычислительном узле в /cvmfs/MyOrg.opensciencegrid.org.Чтобы сделать это переносимым, вы предоставляете сценарий установки, который может выглядеть примерно так: 

# MyOrg setup.sh script
export PATH="`dirname $0`/bin:$PATH"
export LD_LIBRARY_PATH="`dirname $0`/lib:$LD_LIBRARY_PATH"

Таким образом, все всегда настраивается относительно того места, где установлен сценарий установки, и поэтому можно перемещать все дерево каталогов.и переименовывается легко.Почему-то я не могу найти простой способ сделать то же самое с пакетами Python.

Варианты распространения пакетов Python

1) Использование виртуальных сред

Я могу создать виртуальную среду рядом с моими каталогами bin и lib, скопировать все это,а затем просто позвоните source /path/to/MyOrgCode/venv/bin/setup.sh в моем скрипте установки.Но:

  • виртуальные среды используют жестко закодированные пути, поэтому я не могу переместить их по умолчанию
  • virtualenv имеет параметр --relocatable, но есть много предупреждений о том, какэто может испортить вещи.Кроме того, насколько я знаю, virtualenv считается устаревшим в пользу python -m venv
  • Поскольку venv обычно устанавливается где-то без разрешений на запись, пользователи не смогут устанавливать дополнительные пользовательские пакеты дляразвитие, так как pip install --user не работает в venv.

2) Установка по требованию

В моем скрипте установки есть строка pip install -r requirements.txt.Это имеет ряд потенциальных проблем:

  • Где установить?Установка --user будет загрязнять пользовательские настройки Python по умолчанию и может иметь неожиданные последствия.Можно ли использовать venv, но тогда куда мы его поместим?
  • Это действительно неэффективно, если пакеты содержат много кода для компиляции или включены большие наборы данных
  • Если мои пакеты python находятся в частной VCS, мне нужно распространять учетные данные для доступа с помощью сценария установки, которыйв общем, будет доступен для чтения любому, кто знает URL.

3) Использовать PYTHONPATH

Сколько бы у меня ни было пакетов python, поместите их все в мой репозиторий и затем добавьте запись для каждого из них в PYTHONPATH в моем скрипте установки.Потенциальные проблемы:

  • Кажется, я помню, что мне сказали, что изменение PYTHONPATH - это последнее средство, хотя сейчас я не могу найти никаких доказательств, подтверждающих это.
  • Если пакеты находятся в, можно ли его скомпилировать (т. Е. Сгенерировать файлы .pyc?). Есть ли команда, которую можно запустить для принудительной компиляции перед распространением?

Заключение

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

...