Как создать Telegram бота, который создаёт ботов?

Question

[eellazy]

Есть ли какой-то централизованный механизм по созданию или клонированию ботов?

Есть 10 ботов в ходе эксплуатации и тестирования которых возникают баги, которые нужно исправлять. Все они сделаны на основе 1го бота. (банально скопированы файлы бота, создано виртуальное окружение и они себе тихонько работают).
Получается что нужно исправить 10 раз одно и тоже.

Есть у кого идеи по решению данной проблемы? Получается что нужно 1 ядро с которым нужно работать. И при внесении правок или нового функционала это отображается и у других ботов.

P.S
Как устроены конструкторы ботов? Мы даём токен, дальше работаем в конструкторе. Получается, что это можно сделать.

Answer 1

[RTFMaster]

Написать сервис обновления.
На стороне бота написать класс (или метод) апдейтера (не должен зависеть от бота), который будет отправлять на сервис обновления текущую версию бота -> сервис получает версию бота, сравнивает с актуальной версией текущего -> если обновления есть -> вернуть ссылку на zip (при обновлении корневого бота можно автоматически паковать в архив).
Апдейтер (класс) получает пакет, делает бэкап текущего бота куда-нибудь, затирает и распаковывает нового. Версию можно хранить либо файлом, либо свойством, либо вычислять md5 хеш ядра (основного файла бота). Последний вариант мастхэв :)

Comments

[eellazy]

Хороший вариант, но бот в тоже время может быть немного изменён. Например текста которые он отправляет.
Например у одного бота "Hello". у другого "Привіт". А в оновлении вообще "Здраствуй". Получаеться, что везде будет "Здраствуй"

[RTFMaster]

Изолировать рабочую часть (/app) и словари, конфиги, параметры (/config). Если из версии в версию изменяются глобальные параметры или конфиги, то тут уж, простите... либо еще один дочерний слой клиентской конфигурации громоздить (аля адаптер, который будет конфигурацию рабочей части соотносить с конфигурационной и выдавать ошибки, если какой-то компонент в конфиге отсутствует или не проинициализирован), либо заранее определиться с архитектурой и не трогать базовые конфиги :)

Answer 2

[stasersmailov]

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

Comments

[stasersmailov]

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

[Yugh]

stasersmailov, проще создать класс, который создаёт бота, управляет им. Создать конфиг, в котором прописан массив с токенами, от кол-во токенов будет зависеть кол-во ботов.

Просто пропускаете через цикл for массив с токенами и берёте его из конфига, создаёте интерпретатор класса, который создаёт бота

[eellazy]

Yugh, как раз думал о том, что основной бот это класс или модуль в питоне.
Логично ли делать массив текста, токеннов и других данных, а потом передавать их в основной класс бота? Потому что на разных ботах "Мои контакты" могут быть разными

[eellazy]

stasersmailov, Да, бот есть. Но проблема именно в обновлениях и возможной кастомизации этого бота. У моего бота есть база, кнопки и текста.
Идея с одним ботом интересная, но не в этом случае. Так как у каждого пользователя свой бот со своим ником. А тут получается один бот, который всё собирает

[Yugh]

eellazy, Сделай для разных токенов разные контакты и так их передавай