obsproject
Alternatives to discord.py for future development
A few days ago the author of discord.py announced the discontinuation of his development and archival of the project due to not being able to find a new maintainer to continue the work: https://gist.github.com/Rapptz/4a2f62751b9600a31a0d3c78100287f1
This leaves us in the unfortunate position to have to find a new way to continue OBS-Bot development in the future and provide support for new Discord features (context menus, etc.). The most pressing issue is probably the lack of support for threads, meaning we cannot enable them on our server for support use yet.
The primary options I see are:
- Find and adopt and active fork of discord.py (e.g. nextcord)
- Adopt a different library, and rewrite parts of the bot as needed (doesn't really seem to exist?)
- Rewrite the entire thing in a different language (pls no)
Number 1 is obviously the easiest one here, and I'm sure we will see some fork stand out as the most active and most well supported one. But that may take some time. And judging by the commit history of the example named, we're not quite there yet.
This issue will serve for tracking developments in this area.
obs-bot uses so many features specific to discord.py (like cogs) that I feel switching to a fork of it might be best.
For what it's worth, I have a branch that I've been working on that supports semi-private channels with queues, in part because threads did not exist when I started working on it and also because Private Threads require Server Boost Level 2, which can be lost at any time.
obs-bot uses so many features specific to discord.py (like cogs) that I feel switching to a fork of it might be best.
Honestly the use of the cogs system is limited enough that reimplementing parts of it or translating it to another libraries' model probably wouldn't be too hard. Unfortunately it would appear that the only other somewhat popular python discord library disco has also been discontinued. dico may be something to keep tabs on but it is in early development.
For what it's worth, I have a branch that I've been working on that supports semi-private channels with queues, in part because threads did not exist when I started working on it and also because Private Threads require Server Boost Level 2, which can be lost at any time.
Short-term support for threads would still be nice as we figure out what direction we want to take our support structure in.
Mid- to long-term we just need a stable foundation to build on as Discord will add more features, change the API, and possibly deprecate older versions of it (effectively breaking discord.py 1.7.x).
The discord.py master branch has working thread support it just didn't make it into a release but has been working fine for me so far on a small-ish sized server. Just in case you're not aware of that, unless it's missing something still. I recently updated one of my own bots to that for thread support, was a bit of a pain as I was coming from a much older version but no issues otherwise.
Might be fine as a stopgap until it's clear if any of the forks pan out.
As an update for this, we're likely going to go with DisnakeDev/disnake which seems to be one of the more well maintained forks.
The current development version has some improvements for interactions, while we only use URL buttons and slash commands in the public facing version of the bot, those changes still make it significantly more straightforward to add them than the original discord.py's "View" model.
So once disnake v2.4 is out we will migrate this bot. As far as I can tell from my local testing with their current git master this won't actually require much in terms of changes to existing code.
Since the new update from Danny about the future of Discord.py (https://gist.github.com/Rapptz/c4324f17a80c94776832430007ad40e6) I was wondering if the OBS bot is still going to migrate to disnake or if it is going to stay with discord.py
It has already migrated to disnake. In the mid-term we migrate back to discord.py once they publish a stable release of the new developments. It's just slightly annoying to deal with their "views" for interactions, but I expect the original to be more diligently maintained than the alternatives.