Лучший способ поделиться / управлять нашей внутренней библиотекой Python между приложениями - PullRequest
4 голосов
/ 05 декабря 2008

Наша компания (xyz) переносит большую часть нашего Flash-кода на Python.

Во Flash у нас есть общая библиотека между нашими приложениями Flash - пакет xyz. Мы можем вносить изменения в пакет, не опасаясь взлома других приложений при их развертывании, поскольку Flash компилирует их код и включает содержимое библиотеки. Мы развернем финальный SWF через RPM, и все готово. Обновления App1 и App2 никогда не повредят App3.

Как бы вы подошли к этому в Python, зависимости от общей библиотеки.

App1, App2 и App3 могут требовать xyz-lib.rpm и использовать одни и те же файлы библиотеки, но обновленный xyz-lib.rpm должен быть явно проверен на соответствие App1,2,3 каждый время появилась новая библиотека, и это просто обременительно.

Мое любимое на данный момент решение - я могу сделать так, чтобы app1.rpm включал библиотеку с момента ее упаковки - фактически, это своего рода статическое связывание библиотеки. Это, однако, чувствует себя не изящным. (хотя единственная дополнительная плата - это место на жестком диске == дешево.)

Я знаю, что надежное управление разделяемой библиотекой, вероятно, является лучшим решением, но я продолжаю пытаться учесть, что все разработчики - люди, и будут делать ошибки. Мы будем совершать ошибки, и я не хочу, чтобы развертывание app1 сломало app2 и app3 - это просто намного больше для тестирования и отладки.

Ответы [ 3 ]

4 голосов
/ 05 декабря 2008

«явно проверено на App1,2,3 каждый раз, когда появилась новая библиотека» на самом деле не так уж и обременительно.

Две вещи.

  • Вам необходим формальный набор модульных тестов API, которые библиотека должна пройти. Это всего лишь API, а не каждый нюанс функциональности. Если это пройдет, то ваши изменения хороши. Если это не удастся, ваши изменения сломали API.

  • Вам также необходим набор модульных тестов для функциональности, отдельный от API. Это больше и может быть классифицировано как "обременительное".

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

1 голос
/ 05 декабря 2008

Я также предпочитаю решение собрать все воедино и ограничить зависимость от библиотек ОС до минимальной (glibc и все тут). Жесткий диск дешев, клиент и время поддержки нет.

В Windows это тривиально с py2exe + InnoSetup.

В Linux это выглядит так: bbfreeze - верный способ справиться с этим. Цитируя с домашней страницы, он предлагает:

  • отслеживание импорта zip / egg файла: bbfreeze отслеживает импорт из zip-файлов и включает целые файлы egg, если какой-то модуль используется из eggfile. Пакеты, использующие модуль pkg_resources для setuputils, теперь будут работать (новые в 0.95.0)
  • отслеживание бинарных зависимостей: bbfreeze будет отслеживать двоичные зависимости и будет включать библиотеки DLL и общие библиотеки, необходимые для замороженной программы.
1 голос
/ 05 декабря 2008

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

Это может быть полезно, если вам нужно предоставить приложению собственную версию библиотеки.

...