Большая система с плагинами, плагины регистрируют функции (для общего использования) в синглтон например: “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 - от простого к сложному плюс использование разных техник. При этом достаточно сжато.

Мне еще нравится подход Ноа Гифта, соавтора книги Питон для Юникс и Линукс.
Он предлагает очень простое решение,
которое хоть и идет в разрез с PEP, но простота подкупает. Мол, если и использовать такую директиву, то как раз для плагинов. Вся логика подключения, включения и регистрации размещается в __init__.py

Что касается организации системы, все таки маловато данных, чтобы высказывать однозначное мнение.
Исходя из написанного,
1. Потенциально система “все в одном” выглядит монстром, отъедающим память.
Но, если все плагины задействованы или можно их вкл/выкл на лету, то все может ОК. “Может”, потому что зависит от инициализации плагинов. Одно дело, когда хранится их список, другое, когда они уже инициализированы.
2. Нужна защита в виде плагин-менеджера для управления и контроля. Чем больше возможностей у плагинов и чем открытее платформа, тем сложнее должен быть контролирующий модуль менеджера. Возможность установить хук на любую ф-ию обязывает.
3. Sandbox присутствует? Плагин в блоке try…except (некоторые путают эту конструкцию с песочницей) тихонько форматирует диск :)
4. Защита от порчи данных хуками есть или не нужна (все строго регламентировано, разработчику багового хука рубят руки и он об этом знает :)? Можно ли откатить действие хука?
5. Интерфейс - это вообще замечательная штука. В Яндексе этот подход используют полным ходом. Он позволил, например, сократить количество логгирующих систем с 15 до 3-4. Цифры точно не помню, но порядок где-то такой.

Вот набросал примерный код: hg clone https://bitbucket.org/lega911/eps

1. Потенциально система “все в одном” выглядит монстром, отъедающим память.
Но, если все плагины задействованы или можно их вкл/выкл на лету, то все может ОК. “Может”, потому что зависит от инициализации плагинов. Одно дело, когда хранится их список, другое, когда они уже инициализированы.

По идее она не должна отъедать память, т.к. экземпляры не плодятся - “синглтон”, который содержит ссылки на ф-ии. Да и сам по себе “код” не должен много есть памяти, память начинает кушаться когда код генерит всякие объекты.

2. Нужна защита в виде плагин-менеджера для управления и контроля.
3. Sandbox присутствует?
4. Защита от порчи данных хуками есть или не нужна

Особо контроля, думаю, не нужно. Разработчик системы будет отвечать за плагины которые он установил, все равно плагин в текущем приложении толком не оградить - всегда есть возможность напакостить. Ошибки плагинов (и всего остального) будут ловится стандартно - через try/except на каком-нибудь уровне.

Покликал по ссылкам выше, большинство похоже на “Publish–subscribe pattern”, у меня по сути тоже только подписчики имеют приоритет и связаны между собой.

o7412369815963
По идее она не должна отъедать память, т.к. экземпляры не плодятся - “синглтон”, который содержит ссылки на ф-ии. Да и сам по себе “код” не должен много есть памяти, память начинает кушаться когда код генерит всякие объекты.

Тоже верно.
Я код глянул одним глазом. Примеры с серверами специфичны и их старт при инициализации - естественно. Без куска памяти тут никак не обойтись.
В любом случае, вы все равно управляете подключением плагинов через конфиг файл.
Если начнет кушать память, достаточно будет отключить плагин в продакшн, сделать тестовую сборку, с помощью Heapy выполнить замеры и устранить проблемы.
Система вполне стройная при условии предварительных проб новых плагинов на тестовом сервере, чтобы продакшн постоянно не перегружать.

Прошу воспринимать вышеприведенные вопросы исключительно как чек-лист для самопроверки, а не как критику.
Лечение через интернет чревато, как вы сами понимаете :)

У меня тут свой интерес появился.
Скажите, а почему вы решили сами писать плагин-систему, а не использовать готовую?
Если это не связано с fun, а именно осознанный выбор, поделитесь опытом пожалуйста.

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

Что то ничего не приглянулось, хотя особо не искал, да и программа была уже написана, плагины писались уже позже, специально под программу, потом несколько раз мутировали и пришли примерно к такому виду.
Да и чего из-за “10 строк кода” подключать библиотеку, которую наверно ещё захочется попилить.
А вообще мне нравиться велосипедо-строение, в разумных пределах, конечно же. :)