surpathhub / dayong Goto Github PK

Dayong's features are contained within cogs, otherwise known as extensions. As such, it makes sense to define an event listener in the cog for certain features. However, due to how discord.py implements event listeners for bots or cogs, overriding an event like on_message is a fatal mistake. Doing so will overwrite any other explicitly defined on_message method or function found somewhere else in the codebase. It may be fine for a bot with a fixed number of features, but for a multipurpose bot, like Dayong, at scale, it's bound to cause a number of issues.

Solution
I thought about moving the event listeners in a separate directory with each event having its own module. We only have to overwrite an event listener once. I think this looks OK:

Dayong
├── README.md
└── dayong
    └── listeners
        └── on_message.py

# on_message.py
from dayong.cogs import moderator

@Cog.listener()
async def on_message(self, message):
    # Mod is a cog loaded in another module so it doesn't need to be
    # instantiated here. I would recommend using static methods or
    # functions for features that require the use of event listeners.
    mod = moderator.Mod

    # Run coroutine that checks if there are bad words in the message.
    # delete_vulgar_message() is a static method denoted by the `staticmethod`
    # decorator.
    await mod.delete_vulgar_message(message)
    ...

In the above code, I registered the delete_vulgar_message() feature from the cog moderator.py. The feature takes the Message instance as an argument and does its job on it.

Additional Context
External event listeners allow you to hear and handle multiple events from different servers, channels, users, etc. A single listener for a specific event is usually enough to handle different operations.

• https://discordpy.readthedocs.io/en/stable/ext/commands/api.html#discord.ext.commands.Bot.listen
• https://discordpy.readthedocs.io/en/stable/ext/commands/api.html#discord.ext.commands.Cog.listener

The whois command is missing from the commands documentation.

Also, please document event listeners/handlers. They should be in a table, in a separate file called events.md, inside the docs directory. The table should have a name and a description column. In the name column is the event listener's function name, and in the description column, the first paragraph of the function docstring.

An event listener has this decorator:

Shields or badges allow you to show the state of a project to users. Sometimes they also show how much effort and dedication are put into the project. For now, we want to show the python version (3.9 and above), license (MIT), project version, and commit activity.

Please provide a description below the header 1 about Dayong

We think it's only appropriate to provide an example component for users who want to add their own commands/features. Although the libraries Dayong uses already provide the needed examples, we believe adding our own would make the bot more user-friendly.

Using hikari-tanjun, please provide a descriptive, simple, and easy-to-understand example of a message command, a slash command, and an event listener.

Here are basic examples provided by tanjun we can use as reference: https://github.com/FasterSpeeding/Tanjun/tree/master/examples

The sole maintainer of discord.py has ceased the development of their API wrapper. This is my first time making a complete discord bot, so I wasn't aware of this matter.

The reason I chose discord.py was because of its popularity and that it was a fast and mature library. Now that discord.py is essentially dead, we're left with a few options:

1. Rebuild the bot in another language.
2. Rebuild the bot with another library.
3. Extend discord.py to support slash commands.

If you read Danny's announcement, Discord is forcing bot developers to use slash commands. Dayong will die in 8 or 9 months if we continue using discord.py's design model.

Regarding our remaining options, from a project maintainer's point of view, the first one sounds like our top choice, but we don't have to abandon Python just yet. Personally, I think the second or third is our best option. For number 2, I'm looking into other libraries, such as hikari, which is starting to gain traction after the announcement. For number 3, there's discord-interactions, which is a discord.py extension for supporting slash commands.

As we add more features and integrate third-party software into Dayong, the more monolithic the bot becomes.
Monolithic software is hard to maintain and develop. It is also prone to low cohesion and tight coupling, which we prevent by implementing interfaces and design patterns. However, it still takes a few days for new developers/contributors to start writing productive code. From now on, I suggest we implement extendable/big features that take a lot of resources as a microservice.

The fitting approach is to decompose Dayong by following an API gateway pattern, where large, resource-intensive features/services are collectively or individually packaged and deployed to their own domains. This results in a stable architecture and services that are cohesive and loosely coupled. This also allows users to integrate their preferred or private services into Dayong with minimal code and labor.

For more information on microservices, see:

• https://www.infoq.com/articles/microservices-intro/
• https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
• https://microservices.io/patterns/decomposition/decompose-by-subdomain.html

To some degree, Dayong allows high-level customization through the config.json file. Although we only use it now to change how we experience commands and interactions, it's likely to cause erroneous behaviors, especially as the config file becomes larger as we add more features that rely on it.

Configuration checking helps us avoid any problems that may arise from using the config.json file by first verifying that software requirements are met. It's basically just a process that tells us whether a configuration is good or bad. Dayong does not have that kind of functionality yet.

Specifically, compile everything that needs to be edited by the user into a single file. For example, we have config.json and embeddings.json. It'd be nice to have just one configurable JSON file.

Editing configuration files can become quite frustrating and tedious, especially if you have to move from one file to another. The solution is to try and keep everything necessary for the user at the root directory, e.g., move the contents of embeddings.json into config.json.

Dayong has an event listener called greet_new_member(). It fires whenever a new member joins the server.

The code above is supposed to retrieve nested objects from the config.json file in the greetings_field key.

Expected result:

Dayong greets the new member in a channel specified in the config.json file.