Зависимости продукта: вызвать переустановку

Question

Я разрабатываю продукт для Plone, скажем foo.core. Помимо этого основного продукта, есть также несколько связанных продуктов. как foo.optional. Эти выпущенные продукты могут быть доступны в экземпляре, и если они доступны, они могут быть установлены (другими словами: я не могу предположить, что код доступен или, если он есть, его следует использовать).

Эти сопутствующие продукты могут переопределять настройки, установленные foo.core (например, в ведомости свойств). Это работает нормально, но если я переустановлю foo.core, настройки по умолчанию вернутся. Я хотел бы как-нибудь автоматически переустановить foo.optional, когда foo.core переустановлен в QuickInstaller.

Я мог бы предложить следующие решения:

• Когда установлена ​​foo.optional, она регистрируется с foo.core. последний, foo.core, будет обрабатывать переустановка всех зарегистрированных продукты, когда основной пакет переустанавливать.
• Пакет foo.core запускает событие, которое другое пакеты, такие как foo.optional, могут Слушай. Обработчик события будет затем вызвать переустановку foo.optional.
• Убедитесь, что foo.core не перезаписывает настройки, которые может быть настроен позже другие продукты.

Возможно, есть еще альтернативы? Каким был бы подход «Плониш»?

Редактировать: Я знаю, что использование шагов обновления может быть лучше, чем переустановка продукта. Однако ИМХО проблема остается той же: профиль общей настройки, используемый для этапа обновления, может иметь параметр, который изменяется в профиле общей настройки для пакета foo.optional.

Так что использование шагов обновления делает мою проблему еще сложнее: как мне определить, следует ли переустановить / обновить шаг обновления foo.core, означающий foo.optional? (Предполагается, что foo.core в принципе не знает о foo.optional.)

Answer 1

Решение вашей проблемы гораздо проще, чем вы предлагаете:

Мы НЕ переустанавливаем продукты, как это было в прошлом, когда продукт обновлялся. Переустановка продукта приведет к повторному применению вашего универсального профиля установки, поэтому вы перезаписали свои настройки.

Вместо этого вы теперь предоставляете шаги по обновлению. Например, если вы измените версию своего профиля с 2 на 3, вы получите:

<genericsetup:upgradeStep
  title="Upgrade foo.core from revision 2 to 3"
  description="Adds stuff"
  source="2"
  destination="3"
  handler="foo.core.upgrades.two_to_three.addStuff"
  sortkey="1"
  profile="foo.core:default"
  />

На этапе обновления вы можете делать то, что вам нравится, даже повторно запускать отдельные шаги импорта.

Если обновление вашего продукта не связано с изменением профиля GS, не увеличивайте версию в metadata.xml. В этом случае вам, очевидно, тоже не нужен шаг обновления.

Answer 2

Установка / переустановка не имеет смысла в контексте дополнения. Словарь был изменен на активацию / деактивацию, но этого недостаточно, чтобы понять ситуацию.

У вас есть «настройка», в которой вы применяете профиль конфигурации. Примените снова и снова профиль конфигурации ничего не делает, кроме сломанных существующих конфигураций.

Вот почему каждый участник ответит на этот вопрос, используя шаг обновления. Мы не запускаем профиль при переустановке, мы обновляем дополнения, когда в профиле установки есть некоторые изменения.

Так что, если вы находитесь в случае, когда настройки, добавленные foo.core, изменены foo.optional, вы можете сделать следующее.

С новым plone.registry вы можете добавить обработчик к событиям, связанным с IRecord:

• добавить
• редактировать
• удалить

Рассмотрим документацию:

http://pypi.python.org/pypi/plone.registry

Я сделал некоторый код, связанный с этим, где я хочу перестроить реестр css, когда некоторые настройки были изменены:

https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py

Answer 3

Я подозреваю, что вы усложняете себе жизнь, привлекая историю установки дополнений Plone (которая усложняется "старыми" и "новыми" технологиями, живущими бок о бок). Я бы сделал шаг назад и подумал бы больше о системе плагинов, которую вы пытаетесь спроектировать / внедрить, и избегать включения Plone до тех пор, пока вам абсолютно не понадобится [1].

Вы также можете рассмотреть возможность использования точек входа для реализации хотя бы части системы плагинов:

• http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins

[1] Предполагается, что Plone является строгим требованием, и что вы создаете приложение, управляемое контентом, иначе вам, вероятно, следует использовать Django или Pyramid