Arrange tags in sub-directories to utilise the group feature from tags.py

[Ibrahim2750mi]

According to these lines

# Files directly under `base_path` have an empty string as the parent directory name
tag_group = parent_dir.name or None

tag_group will be None until the tag is in a sub-directory inside bot/resources/tags/ eg: bot/resources/tags/fstring/fstring.md and currently we don't have sub-directories in the folder.

Moving them to sub-directories might also solve #2345 as then the aliases will be listed as bullets under the directory name eg:

NOTE: I have kept the directories name as same as the .md(s) here, it could look a lot better if used correct names in parent bullet.

My suggestion is either we nuke them or sort the tags in the directory to use the group functionality of the code.

[janine9vn]

The intent was to sort tags into groups and sub-directories but no one has taken it up yet. I'm firmly against removing this feature just because we haven't used it yet.

For instance, all the d.py related tags can go into a subdirectory, it just requires someone making that PR

[Ibrahim2750mi]

This is the reason I made the issue(if there already an issue for this, then I am sorry), I could sort them up in the sub-directories.

But first I think we need to finalise the groups we are going to have. I am thinking something along these lines.

• python-strings
  Tags related to strings fstring, str-join etc.
• python-discord
  Tags related to us like codeblock, ytdl, xyproblem etc.
• discord.py
  Tags related to d.py
• A-vs-B (can't seem to figure out a better name for this but we have a lot of tags with this format)
  The tags with titles like A vs B, positional-keyword, param-arg etc.
• python-gotchas
  The common python gotchas like if-name-main, or-gotcha etc.
• python-beginner-syntax
  All the beginner tags like comparison, return, self etc.
• python-advance
  Stuff like dunder-methods, list-comprehensions etc.
• python-environment
  Stuff outside python code like pep-8, microsoft-build-tools etc.
• python-errors
  Tags related to errors like nomudle, empty-json etc.

I feel like there can be more groups added to lighten up python-beginner-syntax. Help to suggest group names is appreciated.

[janine9vn]

I don't think we need to create groups for every single tag or for most tags. Any additional grouping we add means you need an additional term to invoke it. With your proposal, calling the pep8 tag would be !python-environment pep-8. So I want to really avoid grouping things just to group them, there should be a natural purpose to it besides "we're not using this code feature yet." The purpose behind groups was to avoid cluttering the namespace and avoid conflicts around calling tags, so that should still be kept in mind.

For me, the group names that make sense are:

• dpy
• python environments, although I would want to add a shortened alias for this groupname
• server (for tags that are just about our server or other discord servers like faq, guilds, site, tools). This one we'll have to be careful with because if we put any commonly invoked ones under here, it's going to be annoying for regular users that they can't direct invoke anymore.

Also, I don't believe this solves the aliases being listed issue. It just sorts the duplicated names for tags, it doesn't reduce the total clutter or duplicate-nature of it.

There is an existing issue for utilizing the tag groups as well for some specific tags:
#1835

Side note: it seems the slash command for tags wasn't tested with tag groups, because the functionality of tag groups has been changed and is no longer really working. It was working when I was testing it with the alias feature though.

[Ibrahim2750mi]

Can't we do something like we only require the group name for triggering some specific group tags, an example would be dpy and use the other groups to list the tags in the embed more cleanly? We can check if the tag.group is an enforced(enforced meaning it would require the user to add the group name before the tag to invoke it) group if not then it can be triggered by both !group tag and !tag? For dpy we can make it an enforced group.

Also for the slash commands I think we can make it probably ignore all the groups and use the tag name directly.

[janine9vn]

I like the idea of having an enforceable tag group vs not. It lets us keep things a bit organized without sacrificing fast tag invoking, but if needed we can still de-conflict tag invocations. Will probably need a core dev weigh in as it changes the original scope/intent of the feature.

I think the slash command should match whatever the !tag does, just for consistency. It would feel weird to have the two ways to invoke a tag be different.

[Ibrahim2750mi]

I think we are on the same page now.

[RohanJnr]

Currently, the new /tag command has the syntax: /tag name:<group_name> <tag_name>. To use a tag from a group, group name has to be mentioned. This could be quite unintuitive to always enter the group name for a simple tag search. Incase if we are enforcing group name, lets try to keep them as simple as possible and short as possible.
Another approach would be to invoke a tag regardless of its group. Incase there are tags with the same name in multiple groups, the user will be prompted to choose from one group (using buttons here would be nice).

Also, do we want to categorize tags on the site into different urls?
I believe with the current implementation on the site, tag groups will be listed as folders on the site and tags inside them.
python-discord/site#763

[HassanAbouelela]

As Janine pointed out, the tag functionality was greatly reduced with the slash command migration. I’m guessing slash commands don’t allow you to enter invalid commands? That is in part how we were handling tag matching before slash commands (its in the error handler).

If we can’t reimplement this flexibility with the slash-commands, then I don’t think this is a good use case for them, and we might be better off reverting these changes. Slash command benefits don’t outweigh the flexibility.

[RohanJnr]

I’m guessing slash commands don’t allow you to enter invalid commands?
slash commands are kinda gimmicky, like you have to explicitely tell discord that you are providing a value for the name argument and only then the error handling takes place

In the case below, discord correctly parses the name argument

sometimes it just doesn't