Support slash commands

[Darkflame72]

The Problem

Slash commands are going to be added to the discord api as of December the 15th. They provide a new way for discord bots/integrations.

discord/discord-api-docs#2295

The Ideal Solution

A way to add slash commands natively as part of a discord.py

The Current Solution

Nothing currently exists

Summary

Add support for discord's new slash commands

[polyjitter]

This one may take some time to see in discord.py proper, seeing as it would likely require either a complete redesign or secondary implementation of the commands extension, and a bit of hefty planning for basic library functionality.

For now, it appears someone has made an unofficial extension to support slash commands. It's third party, so here there be dragons etc, and it doesn't seem to support more complex features slash commands bring, but it may be an option in the interim:

https://github.com/eunwoo1104/discord-py-slash-command

[polyjitter]

I believe that most people following this repo will also be in the know from other sources, but passing this on as an update to my previous comment, the tag related to slash commands from the discord.py server:

slash commands are a new way to make commands right within discord, discord.py will probably not support them as they are lacking features and requires a major rewrite to handle

bad command handler:

• no default argument system - the argument isnt passed if you dont pass it making handling harder
• no Union/Optional system like dpy
• cant handle arguments yourself - required to use there parser
• no way to invoke group command - you can only invoke the subcommands
• no command aliases

limitations:

• 15 mins max per command - a token lasts 15 mins
• only one message can be hidden (the first one)
• hidden messages cannot have embeds
• without a bot token you cant do much apart from send messages and etc - no api interaction
• you only get ids for the parameters - if the parameter is a user you only get there id
• if using the webhook based intergrations you cannot get any other events so you are limited to commands

if you do want to use them there is a half maintianed fork that has support for them ( we will not support them here ) if you wish to use them.
https://github.com/Zomatree/discord.py/tree/slashcommands - no docs because im lazy

TL;DR - Unfortunately, it appears discord.py proper is unlikely to support slash commands due to some drawbacks in comparison to ext.commands. There is a non-supported fork which one may use, if you want the new features such as the command autocomplete, hidden messages, and context system messages. The above linked option still seems viable.

[redgoldlace]

The current sentiment is that slash commands as a whole are not at a stage where implementing library support for them is worthwhile. If the system in its entirety gets improved in the future that may change, but for now it's probably best to sit tight or use the fork, as previously mentioned.

[FaisalAbusharar]

Yep, also i don't know if they are any good to implement into a bot that has a lot of commands.

…

[Znunu]

What happened here?

[ShadowJonathan]

@Znunu someone spamming some comments about the (current) usability of slash commands, don't worry about it

[spinnerich]

Looks like Slash Commands will get some nice features like a permissions system and server-side argument validation
discord/discord-api-docs#2490

[remyjette]

I would also say that a big advantage to slash commands is the visibility in the UI.

Users don't need to do !help to discover what commands are available (which also clutters the channel), the can just type / and see all available commands with descriptions. And as they type the UI displays which arguments they can pass, as well as which arguments are required. If an argument has a limited set of options that's displayed in a much cleaner way. Sure you can provide this information via !help, but paging through a long !help is not a great user experience (plus you have to know which prefix the bot is configured with to even invoke !help in case it's not !)

There are definite limitations for slash commands compared to discord.ext.commands as documented above. Some are marked as being addressed in the issue @MrSpinne linked, some are not. But regardless, the native support for it in the client UI is a huge boon for usability and discoverability for users so I would hope that at some point discord.py could add support even if it's a longer-term goal.

[i0bs]

What really has me sold about the slash commands that we've got lately is how user-friendly they've become with the UI to help guide users to using commands. In the past, we've had to type a help command or look at some personal bot website to understand the context of how they function, but now, that's all changed merely to a description for each option, each choice, and etc.

Idealistically, the only thing that slashes commands should be different than the commands we can already create and implement into our own discord.py bots should be the UI, everything should in my eyes come natively. Guild/role permissions, requirements, no limit to choices for options, and etc. are many things that we are still waiting to seek for slash commands to receive, either via. un-official 3rd party support or by the developers at Discord themselves.

Because of this, I continue to believe that we should seek to be able to code slash commands as an actual usable thing for the discord.py library, not because they're something new and trendy, but simply because this library is an API wrapper in and of itself. The main purpose it overall serves is to help make the Bot API easier to use with Python, and by those means, we shouldn't limit ourselves from implementing slash commands as well. They may not be used as much as regular commands, for sure, but in the future, we won't have to worry about having to code it later than doing it now. This is at least my consensus on it, and I think others might agree.

[ghost]

Someone should pin this, because too many people ask about the same thing.

[Rapptz]

Interactions (as the API calls them) will be implemented when they're in a state of good usability. I'm unsure when that will be but the API is currently in flux and in "public beta" with promises of partial backwards compatibility. I do not particularly want to use this library as their testing bed since the library is more conservative towards breaking.

I have no immediate plans to support it as-is but in the future when the ecosystem evolves and it becomes less of a burden it'll be possible to implement it within the library. Not because of slash commands but because of other types of interactions that will be in the API such as buttons, models, etc.

As of now, this issue keeps kind of spiraling and becoming a maintenance nightmare. It'll be closed when it's implemented, whenever that is. Just don't hold your breath on this being any time soon. For now, I'm locking it.

[Rapptz]

Implemented.