ekonda / kutana

The library for developing systems for messengers and social networks
MIT License
72 stars 17 forks source link

Создание инфраструктуры #75

Closed nukdokplex closed 1 week ago

nukdokplex commented 1 year ago

Предупреждение: это не Feature Request! Можете считать это предложением по созданию платформы/фреймворка. Если это произойдет, я обязательно впишусь.

Обдумав ответы на 3 моих предыдущих issue, я пришел к очень интересному умозаключению, которое может положить начало новому проекту. Давайте по порядку.

Проект Kutana действительно может остаться собой, не потеряв при этом ничего. Однако, его всё еще мало для того, что хочет видеть народ. Я предлагаю начать разработку мощного фреймворка для построения self-hosted ботов. Давайте пока что, как эскиз, назовём его Katuna, в противовес Kutana.

Зачем?

Упростить разработку ботов, конечно же! И дать разработчикам обширный перечень инструментов для этого. В моей голове я это вижу, как аналог Red Discord Bot, только гораздо мощнее.

Архитектура

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

Базовый функционал

В качестве базового функционала я рассматриваю пока два краеугольных базовых плагина: help - как понятно из названия, встроенный плагин справки. Этот плагин будет автоматически собирать из других загруженных плагинов справочную информацию, чтобы отдать её пользователю бота. Разработчикам сторонних плагинов нужно будет лишь рассказать, как оставить эту справочную информацию в командах их плагинов. plugin - этот плагин и его команды будут отвечать за получение/обновление плагинов из репозитория. В качестве репозитория, Red (если грубо говоря) использует github-репозиторий, в котором хранится файл со ссылками на сторонние github-репозитории с плагинами. Сторонние разработчики смогут добавлять свои репозитории в этот файл с помощью пулл реквестов. Удобно, не правда ли? Для установки или обновления, этому плагину нужно будет просто использовать утилиту git и просто клонировать или обновлять локальные репозитории. Вкратце, так устроена дистрибуция плагинов в Red.

Что мы получим?

Прежде всего мы получим платформу для создания ботов. Прекрасный инструмент, который позволит создавать ботов и вовсе без навыков программирования. Буквально, ввел пару-тройку команд, настроил, запустил и мгновение спустя отдаешь боту команды на установку плагинов на свое усмотрение. Грубо говоря, собираешь своего бота, как конструктор. Могу привести аналогию: словно ты установил игру и не зная ни одного языка программирования, устанавливаешь в него различные моды.

Заключение

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

michaelkryukov commented 1 year ago

На данный момент запуск kutana с нуля выглядит примерно так:

Это уже похоже на конструктор, только кирпичиков не хватает). Если действительно хочется что-то придумывать с вовсе без навыков программирования – надо думать над созданием графического интерфейса, или веб-интерфейса, через который можно будет управлять тем, чем сейчас надо управлять через терминал. Не думаю, что есть смысл этим заниматься, по крайней мере сейчас.

В итоге, на мой взгляд, нужно скорректировать CLI интерфейс запуска kutana, задокументировать его, и сделать отдельный репозиторий с морем классных и согласованных между собой плагинов, которые будет просто установить и использовать. Скорее всего, именно это и нужно "народу" (чтобы бота можно было запускать из одного файла с токенами и списком плагинов), и покрывает все аспекты, затронутые в этом issue.

Я могу сделать репозиторий kutana-plugins, и туда можно будет "вписаться" созданием плагинов. Аналог /help уже есть в примерах плагинов – https://github.com/ekonda/kutana/blob/master/example/plugins/plugins.py. Ну и создать issue для правки CLI + переписывания документации.

P.S. Я не уверен, на сколько внедрение функционала добавления плагинов "на лету" действительно критично для большинства пользователей. Просто "отредактировать файл со списком плагинов и перезапустить" должно быть более чем достаточно.

nukdokplex commented 1 year ago

Если действительно хочется что-то придумывать с вовсе без навыков программирования – надо думать над созданием графического интерфейса, или веб-интерфейса, через который можно будет управлять тем, чем сейчас надо управлять через терминал.

Графический интерфейс - это немного чересчур для бота, особенно, когда в большинстве случаев бот запускается на Linux через SSH. Использование интерфейса команд прямо в мессенджере - это гораздо более лаконичный вариант, на мой взгляд, опираясь на опыт Red.

В итоге, на мой взгляд, нужно скорректировать CLI интерфейс запуска kutana, задокументировать его, и сделать отдельный репозиторий с морем классных и согласованных между собой плагинов, которые будет просто установить и использовать.

Для того, чтобы разработчики разрабатывали согласованные между собой плагины - нужно их стандартизировать, нельзя полагаться на стороннюю реализацию - лично я рекомендую представить плагины в качестве реализации абстрактного класса плагина и добавить полный набор стандартных инструментов (к примеру те декораторы, которые я вам предоставил в другом моем issue, еще было бы неплохо не удалять i18n, а сделать его рабочий вариант, я думаю это не так сложно, тем более уже существует gettext).

В итоге, на мой взгляд, нужно скорректировать CLI интерфейс запуска kutana, задокументировать его, и сделать отдельный репозиторий с морем классных и согласованных между собой плагинов, которые будет просто установить и использовать.

Действительно, сейчас в аргументах запуска бардак, с этим нужно что-то делать.

Аналог /help уже есть в примерах плагинов

Боюсь, это ужасный аналог. Плагины могут представлять собой сборник из нескольких десятков команд одной тематики. Опять же повторяю - идеальный и лаконичный вариант - это писать описание каждой команды в docstring. У python есть средства для их чтения.

P.S. Я не уверен, на сколько внедрение функционала добавления плагинов "на лету" действительно критично для большинства пользователей. Просто "отредактировать файл со списком плагинов и перезапустить" должно быть более чем достаточно.

Боюсь это критично, когда владелец бота устанавливает, подгружает, выгружает (модифицирует) команды через специальный загрузочный плагин. Опять же, сценарий я уже привел:

Буквально, ввел пару-тройку команд, настроил, запустил и мгновение спустя отдаешь боту команды на установку плагинов на свое усмотрение. Грубо говоря, собираешь своего бота, как конструктор. Могу привести аналогию: словно ты установил игру и не зная ни одного языка программирования, устанавливаешь в него различные моды.

... прямо, в самой игре! Как например в Factorio.

michaelkryukov commented 1 year ago

Веб-интерфейс для запущенного на сервере бота (или любого другого ПО) – это достаточно стандартное решение в наше время, объективно говоря. Скорее всего, все пользователи предпочли бы его. Даже те, кто привык к динамически подгружаемым плагинам через команды.

Вообще нет необходимости что-либо стандартизировать сильнее, чем сейчас – все плагины реализовывают какой угодно функционал, и могут взаимодействовать между собой как угодно. Для использования gettext не нужно ничего в боте разрабатывать, поэтому модуль 'i18n' и нужно удалить.

Это просто пример, который показывает, что сейчас, без каких-либо доработок можно реализовать плагин с помощью. Не с проста же он в папке "examples"

Существование "плагина для настраивания других плагинов" критично, если кому-то нужно во время работы бота изменять список активных плагинов. Лично я бы однозначно предпочёл создать файл с перечнем плагинов, их конфигураций, конфигурации платформ, и запускать этот файл. Но тут можно подумать.

В общем итог, на мой взгляд – надо просто сделать больше готовых плагинов, и инструкцию из трёх пунктов (установить, вписать настроечки, запустить), которая будет работать. Тогда все хотелки из этого тикета будут выполнены, кроме динамического изменения списка активных плагинов, хотя и это можно, наверное, сделать в качестве простого плагина