Improve extension / plugin loading system

[ascpial]

L'idée est de changer le système de chargement d'extensions pour s'écarter du système proposé par discord.py.
Vous allez me demande "mais pour quoi faire ? ça fonctionne très bien", ce à quoi je vous répondrais "oui, mais.".

Tout d'abord, le système de chargement d'extensions de discord.py n'est pas fait pour charger dynamiquement des plugins relativement complexe, avec des entrées de base de données, des fichiers de traduction etc. Un système customisé permettra de gérer l'enregistrement et la création des tables pour la base de données au moment de la migration vers un ORM, de charger des fichiers de traduction plus facilement, et même de proposer des fonctionnalité avancées comme le fait qu'une API de plugin (par exemple, le plugin xp) soit accessible facilement par un autre plugin, et exposée de manière explicite (sans faire appel à des fonctions utilisées par le plugin xp qui peuvent être changées pour des raisons techniques et casser les plugins qui en dépendent).
De plus, si on compte un jour rajouter un système de "store" pour l'installation et la suppression de plugin, il faudra pouvoir accéder à des métadonnées à propos du plugin, comme par exemple son nom, une description, mais aussi les plugins sur lequel il repose (par exemple un plugin de niveau peut dépendre d'un plugin "librairie" dédié à l'affichage de personnages custom pour chaque utilisateur, voir le projet Dandelion d'Aeris One).

[VForiel]

Intéressant !

J'aimerais bien avoir l'avis de @ZRunner pour savoir ce qu'il est quand même possible a faire via Dpy, au moins pour du court terme, de sorte a essayer de garder l'avantage d'un système maintenu par des tiers (et nous donne donc moins de boulot !), même si je suppose qu'en effet ce changement devra avoir lieu un jour ou l'autre vu nos besoins

[ZRunner]

Pour le court terme, le fonctionnement de d.py me semble suffisant pour la plupart des besoins décrits. Les méthodes de loader/unloader, ainsi que les metadata associées aux cogs, et la forte connexion entre les cogs et les commandes/événements sont de vrais points forts qu’il est facile d’exploiter voire de détourner.
Par exemple, le chargement des traductions ou d’une DB peut facilement se faire dans un cog_load et se décharger dans un cog_unload. Le nom et la description des cogs sont déjà implémentés, et rien ne nous empêche de subclass Cog pour ajouter la liste des cogs requis (ou de le mettre dans un json à côté pour lecture externe). Il n’y a que la partie API que je ne comprend pas.

Cela étant, ce système offert par d.py est relativement basique et évolue très peu. La dernière grosse mise à jour reçue a offert des loaders et unloaders asynchrones par exemple. Lorsque Gipsy passera aux commandes slash (sans utiliser les commandes textuelles ou hybrides), leur utilité sera d’autant plus réduite. Si les limitations apportées sont fondées, il sera alité temps de créer notre propre système. Mais je pense personnellement que ça peut attendre les slash au moins.

[Aeris1One]

Il n’y a que la partie API que je ne comprend pas.

L'objectif serait que chaque extension A puisse exposer des fonctions accessibles par l'extension B qui a déclaré A comme dependance sans que B n'ai à importer A avec un path hardcodé.

Je crois du coup qu'ascpial a prévu un systeme de gestion de dependance et un moyen d'exposer de telles fonctions.

[ZRunner]

Je vois pas comment tu veux appeler une fonction sans hardcoder son nom tbh. Pour moi ça correspond exactement au principe d’interface et de méthode publique, non ?

[ascpial]

Oui c'est l'idée

[Aeris1One]

Je pense que de toute façon cette modification sera nécessaire. Peut-être pas dans la prochaine version, mais de toute façon il est prévu de passer aux slash commands.
Je pense que tu peux commencer à bosser dessus, en répliquant les changements que tu as commencé à faire sur mon Dandelion. De mon côté je vais bosser sur le passage des 3 extensions par défaut (RSS, wormhole et misc) aux slash commands. Cela permettra aussi de supprimer plein de vieilles fonctions librairies qui ne seront plus utiles (i.e. args.py)
Cela permettrait également de faire un passage réellement complet aux slash commands, en retirant la dépendance à discord.ext.commands qui nécessite forcément d'avoir un préfixe pour les commandes.

Ca fera une grosse release totalement backward-incompatible, mais c'est nécessaire pour réécrire le bot d'une manière propre et durable. Ton système sur Dandelion me paraît très propre et sera probablement utilisable en production après quelques itérations de développement supplémentaire.