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

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

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

После того, как разработчики завершат «тестирование» пакета, подготавливается дистрибутив (яичный файл) пакета и помещается в центральное место архивирования. КОГДА мы хотим развернуть наше программное обеспечение для клиентов, те же дистрибутивы (яйцо-файлы) будут загружены и установлены в их среде.

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

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


person None-da    schedule 17.02.2012    source источник


Ответы (4)


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

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

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

person Roland Smith    schedule 20.02.2012

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

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

person darthlukan    schedule 23.02.2012

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

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

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

person PJ Eby    schedule 23.02.2012

Если у вас есть только модули 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-безопасна.

person Dima Tisnek    schedule 08.03.2012