Каковы лучшие практики для создания дистрибутивов Python (яиц) на (и для) нескольких операционных систем
Наш магазин питонов. У нас есть различные пакеты Python, разработанные собственными силами, и они будут развернуты в клиентских средах (машинах).
Так происходит наш цикл разработки и выпуска.
Как только разработчики завершают "тестирование" пакета, готовится дистрибутив (файл egg) пакета и отправляется в центральное место архивирования. Когда мы хотим развернуть наше программное обеспечение для Клиентов, те же дистрибутивы (файлы egg) будут загружены и установлены в их среде.
Предполагая, что "тестирование" происходит в нескольких операционных системах (для проверки совместимости API на разных платформах), что является наилучшей практикой для подготовки дистрибутивов и отправки в центральное место архивирования.
Лучше ли иметь специальные яйца операционной системы на сервере архивации (например, samplepkg-1.0.0.win32.egg и samplepkg-1.0.0.linux.egg? Не знаете, как их можно приготовить таким образом, используя setuptools.) Или есть одно яйцо, потому что API остается одинаковым на разных платформах? Любая другая практика, которой придерживается сообщество?
4 ответа
Вы можете использовать один пакет, если:
- Пакет не использует функции / классы, которые недоступны на всех ваших целевых платформах (см., Например, главы 36-39 справочника по стандартной библиотеке Python для версии 2.7.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-безопасным.