GroupCogMeta overwrites the superclass's command parents about jishaku HOT 4 CLOSED

Fixing this is kind of a pain. The key problem here is that GroupCogMeta is parenting the Commands it sees on the class, but since the implementation is not overridden, the Commands it finds are from the superclass (JishakuBase) and thus they get associated with the a Group owned by the subclass.

The two ways I can think of going about this while maintaining functionality are:

• Creating some kind of 'factory' for JishakuBase-like classes that each consumer should call to receive their own personal baseclass (and thus the Commands of the baseclass being parented is not much of a problem, since it is in effect owned by its subclass). This feels like a pretty bad way of doing it, because dynamically manufacturing new types at runtime makes those types hard to work with (isinstance(x, JishakuBase) would no longer be possible) and it feels like it fundamentally breaks the principle of using baseclasses in the first place

• Creating a more complicated generalized metaclass similar to GroupCogMeta, but instead of assigning the existing commands of the class to a provided parent, instead takes in the parent and defines the Jishaku standard commands. The problem with this approach is that subclass command callbacks wouldn't be able to call back to their superclass versions, since they wouldn't be part of the superclass anymore.

Overall, I think that the class redesign, while allowing for more extensibility, has caused a lot more problems than it's probably been worth. I figure I will redesign it when I have a better idea of how to do it properly.

from jishaku.

This problem is mostly addressed by the jishaku Feature system in v2.

from jishaku.

The command parent must use @commands.group() (a Command cannot have child commands)

from jishaku.

Sorry forgot that when making the reproduction steps, still have the same issue when using commands.group though

from jishaku.