Форум сайта python.su
Большая система с плагинами, плагины регистрируют функции (для общего использования) в синглтон например: “API.http.get”, “API.math.fibo” и т.п.
так же в “одно имя метода” (например “API.http.get”) можно зарегестрировать несколько функций с разным приоритетом (так организованы hook-и).
Ещё пример: плагины для web фреймворков bottle/flask/django… регистрируют методы API.web.route, API.web.start_server и др., в дальнейшем можно легко менять один фреймворк на другой.
Что оно дает:
+ Доступ ко всему функционалу, подключив один объект “API”
+ Возможность установить хук на любую ф-ию
+ Уход от дублирования функционала ( иногда знаешь что где-то реализовывал конкретную функцию но уже не найти или не достать, если она будет доступна в “API.” будет проще )
+ Легко сформировать список всех ф-ий (для общего использования)
+ Использовать как интерфейс? ( например сказать одному разработчику “ты должен реализовать API.facebook.connect, API.facebook.read”, а другому сказать что-б использовал их, в остальном они свободны: название плагина, содержимое…, мне останется только включить плагины)
сюда же можно прикрутить зависимость между плагинами, какой-нибудь API.required()
т.е. получается, что я как-бы ухожу от обычных импортов.
Вопрос, чем плоха такая организация системы? Как улучшить, что почитать?
Офлайн
Как сказал один умный человек, не существует понятия лучших практик для написания плагинов. По крайней мере, задокументированных.
Я когда то искал материалы по этой теме и могу подтвердить мнение Крстича.
Из загашников закладок, краткий обзор систем плагинов со ссылками на первоисточники:
http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html
Обратите внимание на цикл статей Анри Робера в качестве пост-анализа для своей системы, вдруг что-то упустили.
Он написал их в стиле Django Book - от простого к сложному плюс использование разных техник. При этом достаточно сжато.
Мне еще нравится подход Ноа Гифта, соавтора книги Питон для Юникс и Линукс.
Он предлагает очень простое решение,
from plugin import *
Офлайн
Что касается организации системы, все таки маловато данных, чтобы высказывать однозначное мнение.
Исходя из написанного,
1. Потенциально система “все в одном” выглядит монстром, отъедающим память.
Но, если все плагины задействованы или можно их вкл/выкл на лету, то все может ОК. “Может”, потому что зависит от инициализации плагинов. Одно дело, когда хранится их список, другое, когда они уже инициализированы.
2. Нужна защита в виде плагин-менеджера для управления и контроля. Чем больше возможностей у плагинов и чем открытее платформа, тем сложнее должен быть контролирующий модуль менеджера. Возможность установить хук на любую ф-ию обязывает.
3. Sandbox присутствует? Плагин в блоке try…except (некоторые путают эту конструкцию с песочницей) тихонько форматирует диск :)
4. Защита от порчи данных хуками есть или не нужна (все строго регламентировано, разработчику багового хука рубят руки и он об этом знает :)? Можно ли откатить действие хука?
5. Интерфейс - это вообще замечательная штука. В Яндексе этот подход используют полным ходом. Он позволил, например, сократить количество логгирующих систем с 15 до 3-4. Цифры точно не помню, но порядок где-то такой.
Офлайн
Вот набросал примерный код: hg clone https://bitbucket.org/lega911/eps
from api import API def foo(): print 'foo' API.bind('app.go', foo) API.app.go()
1. Потенциально система “все в одном” выглядит монстром, отъедающим память.По идее она не должна отъедать память, т.к. экземпляры не плодятся - “синглтон”, который содержит ссылки на ф-ии. Да и сам по себе “код” не должен много есть памяти, память начинает кушаться когда код генерит всякие объекты.
Но, если все плагины задействованы или можно их вкл/выкл на лету, то все может ОК. “Может”, потому что зависит от инициализации плагинов. Одно дело, когда хранится их список, другое, когда они уже инициализированы.
2. Нужна защита в виде плагин-менеджера для управления и контроля.Особо контроля, думаю, не нужно. Разработчик системы будет отвечать за плагины которые он установил, все равно плагин в текущем приложении толком не оградить - всегда есть возможность напакостить. Ошибки плагинов (и всего остального) будут ловится стандартно - через try/except на каком-нибудь уровне.
3. Sandbox присутствует?
4. Защита от порчи данных хуками есть или не нужна
Офлайн
o7412369815963Тоже верно.
По идее она не должна отъедать память, т.к. экземпляры не плодятся - “синглтон”, который содержит ссылки на ф-ии. Да и сам по себе “код” не должен много есть памяти, память начинает кушаться когда код генерит всякие объекты.
Офлайн
Скажите, а почему вы решили сами писать плагин-систему, а не использовать готовую?
Если это не связано с fun, а именно осознанный выбор, поделитесь опытом пожалуйста.
Офлайн