Работает следующая система:
1. Относительно большая сеть Ethernet со статическими IP.
2. Клиентское приложение на wxPython. Метод развертывания - py2exe -> Inno Setup. Небольшая часть клиентов сидит под Линуксами, для них соответственно - простой архив с описанием требуемых библиотек.
3. Серверное приложение - на Zope 3, с вэб-интерфейсом для администратора.

Что имеем на сегодняшний день:
1. Клиентское приложение имеет конфиг (реализованный для большего быстродействия как SQLite-база), который часто требуестя изменять.
2. Программа стучится на сервер, проверяет нужно ли обновиться и обновляет свой конфиг.
3. Серверное приложение различает клиентов по IP, и для каждого имеет свою конфигурацию для выдачи её клиентам.

Что хочется сделать:
На данный момент программа-клиент обновляет только свою SQLite-базу. А хотелось бы, что бы он могла и сама обновиться. То есть фактически, реализовать автоматическую сетевую установку новых модулей для программы (соответственно, новые wxPython окна), с попутным появлением новых разделов меню или новых кнопок в главном окне.

Позволит ли сделать это windows-клиент, собранный при помощи py2exe, и как ?
Возможно ли извернуться так, чтобы эта же установка работала и у Linux-клиентов ?

может все обновляемые функции вынести в модули и обновлять только нужные модули ?

1) какой дистрибутив линукса?
2) лучше создавать два дистрибутива: для винды - exe или msi, а для линукса свои пакеты, стандарные для этого дистрибутива. так же для линукса, можно работать с *.egg

1) Избавится от py2exe. Python в .msi, AFAIR, позволяет делать неинтерактивную установку, так что поставить при помощи INNO Setup/nsis будет возможность.
2) Обновлять либо при помощи к-л системы контроля версий (bzr, hg, svn - не суть важно), либо яйцами (setuptools/.egg).
3) Избавится от конфига в SQLite, бинарные конфиги это плохо.

j2a
1) Избавится от py2exe. Python в .msi, AFAIR, позволяет делать неинтерактивную установку, так что поставить при помощи INNO Setup/nsis будет возможность.

Не могли бы поподробнее сказать как это будет выглядеть ?

j2a
2) Обновлять либо при помощи к-л системы контроля версий (bzr, hg, svn - не суть важно), либо яйцами (setuptools/.egg).

Существует ли вариант связывания API к-л системы контроля версий с собственой программой (то есть по нажатию кнопки “Обновить” в окне программы) ?

j2a
3) Избавится от конфига в SQLite, бинарные конфиги это плохо.

По большому счету это не конфиг, а именно база данных, просто мы здесь привыкли так ее называть :)

под виндой самообновление py2exe программы проблематично.
можно сделать простой батник, который будет делать автоматизацию этого процесса перед запуском собственно вашей программы. что-то типа такого

http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1033

astoon

j2a
1) Избавится от py2exe. Python в .msi, AFAIR, позволяет делать неинтерактивную установку, так что поставить при помощи INNO Setup/nsis будет возможность.

Не могли бы поподробнее сказать как это будет выглядеть ?

В инсталлятор кладете python<version>.msi и свое приложение. В процессе инсталляции автоматом ставите Python, а потом в %PYTHONDIR/Lib/site-packages/ – своё приложение. Делаете нужные скрипты, ссылки и т.д.

j2a
2) Обновлять либо при помощи к-л системы контроля версий (bzr, hg, svn - не суть важно), либо яйцами (setuptools/.egg).

Существует ли вариант связывания API к-л системы контроля версий с собственой программой (то есть по нажатию кнопки “Обновить” в окне программы) ?

Вполне. Упомянутые выше Mercurial и Bazaar написаны на Python и имеют соответствующие API. К Subversion есть Python-биндинги.

j2a, спасибо, похоже этот вариант самый подходящий.

Но вот еще:

bialix
под виндой самообновление py2exe программы проблематично.

С py2exe особо глубоко не разбирался - прочитал статью здесь, сделал как в ней написано и сдал работу :)
А вот теперь думаю: py2exe формирует архив librari.zip.
Что если бы формировать не архив, а простой каталог ? Может ли py2exe позволить это ?
Тогда можно было бы все необходимые модули в отдельный пакет, который py2exe туда будет запихивать,
а при обновлении - обновлять именно файлы в этом каталоге ?

можно сделать и не в library.zip.
Обновление через egg - интересная мысль.
Системы контроля версий избыточны. Объем на диске как минимум в два раза больше, чем без них.
Есть еще одна интересная проблема. Либо код, осуществляющий обновления, сам лежит в необновляемой части и работает до первого импорта обновляемого куска - либо нужно скопировать обновитель куда-нибудь, погасить программу, обновить файлы, запустить ее снова. reload модулей работает нестабильно, а еще есть опасность попасть на блокировку файла.

По моему, готовых универсальных решений не существует, но вполне можно написать свой частный случай (и я такое делал).

Андрей Светлов
Есть еще одна интересная проблема. Либо код, осуществляющий обновления, сам лежит в необновляемой части и работает до первого импорта обновляемого куска - либо нужно скопировать обновитель куда-нибудь, погасить программу, обновить файлы, запустить ее снова. reload модулей работает нестабильно, а еще есть опасность попасть на блокировку файла.

Основная идея - добавлять новые модули. Они же и должны изменяться/обновляться.
У программы есть постоянная часть, внешне такая же, как и сейчас. Соответственно в главном, постоянном фрейме можно изначально сделать кнопку “Другие модули”.
Событие “Другие модули” вызывает уже изменяющийся модуль с фреймом, кнопки которого зависят от наличия, скажем, каталогов с модулями, и их вызывают.
Допустим, исключаем блокировки файлов. Что бы не делать reload, в логике кода задаем импорт модулей по условию.
Тогда во время запуска приложения динамические модули уж точно не импортируются.
Остается одно:

Андрей Светлов
можно сделать и не в library.zip.

как ?