Создание инфраструктуры about kutana HOT 3 OPEN

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

• Установить модуль kutana
• Скопировать run.py
• Добавить плагины:
  • разрабатывать свои плагины из папки /plugins;
  • закинуть скачанный плагин в папку /plugins (словно это мод для игры)
  • установить модуль через pip install (можно даже из git-репозитория) + добавить app.add_plugins(installed_plugin).
• Запустить бота python3 run.py

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

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

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

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

from kutana.

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

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

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

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

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

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

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

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

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

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

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

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

from kutana.

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

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

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

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

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

from kutana.