Каковы лучшие практики для создания дистрибутивов Python (яиц) на (и для) нескольких операционных систем

Наш магазин питонов. У нас есть различные пакеты Python, разработанные собственными силами, и они будут развернуты в клиентских средах (машинах).

Так происходит наш цикл разработки и выпуска.

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

Предполагая, что "тестирование" происходит в нескольких операционных системах (для проверки совместимости API на разных платформах), что является наилучшей практикой для подготовки дистрибутивов и отправки в центральное место архивирования.

Лучше ли иметь специальные яйца операционной системы на сервере архивации (например, samplepkg-1.0.0.win32.egg и samplepkg-1.0.0.linux.egg? Не знаете, как их можно приготовить таким образом, используя setuptools.) Или есть одно яйцо, потому что API остается одинаковым на разных платформах? Любая другая практика, которой придерживается сообщество?

4 ответа

Решение

Вы можете использовать один пакет, если:

  1. Пакет не использует функции / классы, которые недоступны на всех ваших целевых платформах (см., Например, главы 36-39 справочника по стандартной библиотеке Python для версии 2.7.2 для материалов, которые вы не должны использовать в этом случае)
  2. Вы не используете расширения, написанные на C/C++, которые нужно компилировать для каждой платформы.

Как правило, рекомендуется избегать определенных функций ОС, которые доступны не на всех ваших целевых платформах. Стандартная библиотека довольно хорошо задокументирована в этом отношении.

Я думаю, что в этом случае использование одного пакета будет более сложным по причинам, указанным Роландом выше. В вашей среде разработки у вас могут быть отдельные папки для отдельных платформ, каждая из которых имеет специфический для платформы код (например, расширения / библиотеки, написанные на C/C++). Вам нужно будет имитировать ваши setuptools в этих папках для создания отдельных яиц, но в конечном итоге это будет менее сложно (я думаю, не зная больше о том, с каким кодом вы на самом деле работаете), чем пытаться собрать все в одном пакете.

В любом случае, чтение документации по стандартной библиотеке, а также distutils ( http://docs.python.org/distutils/) должны помочь вам найти ваше решение.

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

Если вы используете инструменты автоматической установки или API-интерфейсы времени выполнения pkg_resources для поиска библиотек и плагинов, вы можете просто сбросить все яйца в одном каталоге, и инструмент установки или API-интерфейс времени выполнения определит, из какого яйца установить или импортировать.

версия tl; dr: способ, которым setuptools создает яйца, - это способ их распределения; если вы попытаетесь превратить кроссплатформенное яйцо в зависимое от платформы или наоборот, вы, скорее всего, испытаете некоторую боль.;-)

Если у вас есть только модули Python, держите все различия скрытыми в Python, будь то одинаковые файлы (python std lib) или отдельные файлы (pyserial).

Если у вас есть скомпилированные модули, это немного сложнее.

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

./lib/display.py  # frontend, platform-independent
./lib.linux-x86_64-2.6/_display.so
./lib.linux-armv5tejl-2.6/_display.so

И этот код в начале начала программы:

sys.path.append("lib.%s-%s-%s.%s" % ((posix.uname()[0].lower(),
                                      posix.uname()[4])
                                     +sys.version_info[:2]))

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

Другие вопросы по тегам