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.

End Command in utils.py

• Allows the termination of the bot in a shorter time. This will help developers that run their programs without IDE.

Test.py

• This is a test file.
• Provides a basic how-to of text embeddings and mentioning a user (currently the author of the message).

The whois command is missing from the commands documentation.

https://github.com/SurPathHub/Dayong/blob/3abcf95101f61c2ce7a819bd26024729ed17e5ad/dayong/components/privilege_component.py#L45

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: https://github.com/SurPathHub/Dayong/blob/3abcf95101f61c2ce7a819bd26024729ed17e5ad/dayong/components/event_component.py#L17

Resolves #4

After much deliberation, I've decided to rebuild Dayong with a different library, hikari.

Extending discord.py was initially our first choice. Developing, testing, and implementing the extension would take months, so that was out. The obvious, best step was to use already existing libraries for that purpose. The best option was discord-interactions out there, which seemed like the answer at first, but after taking a peek at the source code of the current stable build, I determined it wasn’t. I’d rather not deal with endless lines of inefficient spaghetti code. The unstable build is a lot better, but who knows when that'll be ready.

Active forks of d.py do exist, but they were still in the process of monkey-patching, and devs were still developing and testing the interactions module. Moreover, none of them seem to be fully supportive of type hints from python 3.9 and above.

There are a few minor issues regarding the usage of hikari. It particularly involves newbie python developers or maybe beginner programmers in general. I’m mainly concerned with its documentation. It’s not very newbie-friendly, as compared to discord.py's documentation. New contributors will definitely have a hard time implementing features and fixing bugs because they’ll be having a hard time finding the methods and classes they need, but only until they get used to it.

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.

This is the Pull Request for Issue #12 I hope I did everything correct 🙃

If there are issues please let me know and I will try to fix them.

Greetings, lokerhp

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.

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

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

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

https://github.com/SurPathHub/Dayong/blob/3a2fc34614f6509a9385e556f447a994f4e6d7fa/dayong/components/event_component.py#L76

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.

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