DisnakeDev / disnake

An API wrapper for Discord written in Python.
https://docs.disnake.dev
MIT License
721 stars 137 forks source link

feat: application emojis #1209

Closed Mantouisyummy closed 2 months ago

Mantouisyummy commented 3 months ago

Summary

Implements https://github.com/discord/discord-api-docs/pull/7010

This PR is about the Application Emoji feature for Discord.

It's my first time submitting a related PR, and although I've ensured that the functionality should be working, there are probably still some issues. I'm also not very familiar with the docs.

I'm sorry for any inconvenience this may cause. If you have any suggestions or questions, please let me know, and I'll address them as soon as possible!

Checklist

NeloBlivion commented 3 months ago

Hi, don't want to make a big deal out of this or anything but I'd appreciate it if you didn't blatantly copy-paste the code from https://github.com/Pycord-Development/pycord/pull/2501 (including the mistakes in the first version), thanks 🥰

HenrySpartGlobal commented 3 months ago

Hi, don't want to make a big deal out of this or anything but I'd appreciate it if you didn't blatantly copy-paste the code from Pycord-Development/pycord#2501 (including the mistakes in the first version), thanks 🥰

Hi @NeloBlivion, Don't get me wrong, I understand your concern I believe the person who submitted the MR was trying to help, not being malicious. Both projects use the MIT License, and using and sharing code like this is allowed. It’s part of what makes open-source great!

Considering that both pycord and disnake are API wrappers for the same platform, it's natural that similar solutions might emerge, so I don't believe reinventing the wheel is necessary.

NeloBlivion commented 3 months ago

Hi @NeloBlivion, Don't get me wrong, I understand your concern I believe the person who submitted the MR was trying to help, not being malicious. Both projects use the MIT License, and using and sharing code like this is allowed. It’s part of what makes open-source great!

Considering that both pycord and disnake are API wrappers for the same platform, it's natural that similar solutions might emerge, so I don't believe reinventing the wheel is necessary.

Oh yeah, I get it - there's only so many differences you can get between libraries serving the same purpose, that were originally based off of the same project. I also enjoy looking at other library implementations to see how other people tackle new features (especially in updates like these where it can have greater implications on other structures). It's not really a big issue and I don't expect this to close or anything, that being said i just found it strange that someone would directly copy a draft PR to pass off as their own work (obviously it's still under MIT license where this is perfectly fine, but still felt off to me)

anyway havefun i guess

Mantouisyummy commented 3 months ago

Hi, don't want to make a big deal out of this or anything but I'd appreciate it if you didn't blatantly copy-paste the code from Pycord-Development/pycord#2501 (including the mistakes in the first version), thanks 🥰

Thank you for your reply. I apologize for making you think that I copied and pasted your code written in Pycord. In fact, I admired your work so much when I saw your code. Therefore, I studied some of your code and combined it with my own ideas to optimize it. If this has caused you any discomfort, I am truly sorry and ask for your understanding.

Mantouisyummy commented 3 months ago

Since this code will be a breaking change for Disnake, I believe it will differ from Pycord's code, and I will continue to modify it. It is undeniable that my code was indeed inspired by yours, which may have unintentionally included some of your errors. For this, I apologize again. Your code is truly excellent.

Enegg commented 3 months ago

Since this code will be a breaking change

What's the part that makes it a breaking change?

EmmmaTech commented 3 months ago

Pycord is licensed under the MIT License, which gives anyone free reign over its code. It's also inevitable that 2 forks of discord.py will share similar code/implementation details due to the design of the original library and the fact that they are both adding the same features from the Discord API (duh). So disclosing the "original" author/source is unnecessary here, it was just a matter of timing between this PR and the Pycord one.

shiftinv commented 2 months ago

Hi there, thanks for the PR. After some internal deliberation, I'm making the decision to close this.

While other commenters aren't wrong that the MIT license technically/legally allows this, and that both libraries themselves are naturally quite similar by virtue of being forks, I'm not entirely comfortable with merging this PR given the circumstances, sorry.

The base of this PR is quite clearly copied (at least partially) from the original linked PR - looking at a diff of diffs (select "Character" change highlighting) between this PR's base commit and the original PR's first commits up to the same date/time, some sections (e.g. is_usable or _remove_emoji) line up too well for them to just be "inspired" by another PR. Aside from pre-existing differences between the two libraries, most of the other changes seen in that diff are formatting changes or renames, as far as I can tell. You've put in some refactoring work into this PR beyond that, which I don't want to just dismiss here, but it doesn't change the fact that the groundwork is the same.

Even if the license allows it, the fact that there wasn't a single reference to the original PR or any sort of attribution somewhat goes against the open source spirit, imho. The original author has made it pretty clear that they ultimately don't really approve of this - if this was coordinated with them, it would've probably been fine. While maintaining an ideal "clean room" design for a library is probably unfeasible, I think everyone would still appreciate it if PR authors at least majorly author their own PRs.


In terms of implementation, it seems there's still some bikeshedding to be done. Before someone (you, or anyone else) gives implementing this another try, it might be worth talking about some design specifics first, either in a separate issue or #bikeshedding.