Fork support (nextcord, pycord, etc.)

[DavidSenpai]

Discord.py has been discontinued as of august 28th 2021 (https://gist.github.com/Rapptz/4a2f62751b9600a31a0d3c78100287f1) Nextcord is a fork of discord.py which will try to replace discord.py, with continued support and features, to still offer former discord.py users a stable API wrapper for their bots.

Feature request: Jishaku support for nextcord as there is no similair alternative for nextcord https://github.com/nextcord/nextcord

EDIT: https://github.com/ooliver1/jishaku-nextcord

[ooliver1]

lol :notlikeduck:

[scarletcafe]

The README already covers my basic thoughts on forks in details, but if it's just about compatibility, then Jishaku should be compatible with nextcord already. If it's not, it's a nextcord bug, not mine.

While writing up the rest of the rest of this post, the amount of tangents became too annoying to resolve so I've decided to break this into two sections - 'useful information' and 'my opinion'. Consider this the reference for attitude to forks for at least the near future.

Useful information

Jishaku intends to keep supporting the original discord.py at the current PyPI (1.7.3) and git (2.0.0a3575+g45d498c) state, for at least as long as they continue to work. Since as far as I'm aware, code from even 0.16 is still functional, it is likely this period will be either 'indefinite' or 'a really long time'. Pull requests that break functionality with these base versions will be considered incomplete and won't be merged.

However...

I don't really feel like obstructing developer's judgements regarding whether they decide to use a fork or not, or what fork. That is - the commitment to supporting the base library is not a commitment against supporting forks.

For the sake of my sanity though, this courtesy extends only to forks that provide the discord package/namespace to a suitable degree of compatibility with the base version.

This does not have to be a default behavior, it can be shimmed or an optional feature, but if the package isn't provided, or it isn't suitably compatible with the original, it will be considered out of the support scope. I can't be expected to double or triple the amount of work I have to do to for libraries that don't follow the dress code.

To that end, subject to alignment with normal contribution standards,

I will most likely accept changes that...

• Generally improve the support scope of Jishaku in an unopinionated manner. There aren't too many changes that can fall into this category, but one would be the recent change to the Jishaku base command to better determine what is providing the discord package. This improves support for all forks regardless of their nature.

• Add, improve, or fix functionality in a fork-agnostic way. This basically extends to changes that would have been accepted before the fork split. I obviously am still interested in improving the quality of Jishaku as a whole.

I will consider...

• Smaller feature-detection based changes that allow Jishaku to do its job better if a fork has implemented e.g. new functionality in relation to an existing Discord feature. This is sort of broad, but as a general example, if Discord implements the ability to 'foobar' a message, then changes that detect e.g. an add_foobar method to utilize it will be considered as long as the interface is suitably agreed upon.

• Minor patches for interface changes, so long as there as actually a good reason to do so. If a fork decides to change the call signature or name of a method, I'm willing to path on it as long as it makes sense why that would be done. For instance, if Discord released some 'Asset' feature, and it was opted to rename discord.Asset to something else to accommodate the new model, I would be willing to handle it because it makes sense why you'd do this. If a fork, however, changed fetch_member to acquire_participant, I wouldn't support it because it's silly and there's no obvious good reason to do it.

I won't accept changes that...

• Aggressively sway in favor of a given fork. Examples of this would be shimming the discord package for a given fork within Jishaku itself, or creating new Feature classes that only work with one fork in mind. Open source is about openness, we're all friends here, agree on an interface and then come back when there's suitable alignment.

• Break compatibility with a given already-supported fork without a good reason. I intend to be courteous to all those that meet my requirements, so strange foul play will obviously not go down in my book.

I hope this has mostly cleared up my stance on fork support as a whole. Library development is not supposed to be a competition, so meet the base requirements and you should be in support scope by default.

My opinion (i.e. the not useful stuff)

As detailed in the README before, I don't really trust any forks myself. I've been on Discord since late 2015, and I largely sympathize with Danny's reasons to stop developing it, as do many of the other mainline contributors. It's for this reason that the library stopped development instead of being passed onto someone else; everyone who knew what they were doing turned down the offer, as we've all been at the receiving end of Discord's disrespect ourselves.

All of the real forks that exist are mostly from those relatively uninvolved in the community, i.e., people who don't have much experience with the library itself, let alone maintenance of it. I've not been super impressed so far with the code quality of the forks I've seen. A lot of them seem more interested in putting effort towards 'heightening their brand' -- trying to create the most flashy logo, README, GitHub org, server, etc etc, to convince people that they're the fork. Some of them (including nextcord IIRC, before they went back on it) also tried to migrate package names, which just causes unnecessary end developer work for no reason.

To a degree, I'm not really surprised. A lot of people used discord.py, so the aftermath of its discontinuation is a great time to exploit people's uncertainty, and for that you need business sense, not programming skill. But from my perspective, I don't care how good a fork looks on its business card, I want to depend on things that will work well. To that end, I care very little about fork in-fighting and drama and would rather not contribute to it myself.

While I still think of Jishaku as not much more than a hobby project, I think it's undeniable that choosing to target something would sway people's opinions on what they should use. I refuse to cause that drama unless I can objectively speak for the benefits of doing so, and right now, there's not really much to speak of at all. Perhaps in the far future, if a fork arises or refines itself to prove its standard of consistent quality, I might end up targeting it, but I just don't really see it happening. If anything, it's probably not going to happen while every fork is reaching into the candy bowl for developers to pull onto their ecosystem.

[ooliver1]

I do support your opinions about this as we can all agree that discord isn't treating devs right.

In fact one experience myself is slash autocomplete not working as intended, me reporting it then they just ignored it

[ghost]

discord.py is alive