Define config basis

[cyrus01337]

~This may need a better name.~

Following up on fa86960c836779e45e9b869f6ca2a614539a79c1, big fan of defining/potentially overriding parameters using keys in this way, wondering if setting up defaults would be a good idea moving forward. Building from this design, categorisation personally made sense in a way where categories were defined as separate entries and referenced within command definitions:

[category.General]
description = "General commands"

[command.say]
description = "Make me say anything!"
category = "General" 

Ultimately, definition doesn't matter here - we could opt out since TOML is fine with defining entries that don't explicitly exist ([main.sub.child] creates main, then main.sub, then main.sub.child) and even let tomllib handle this altogether.

There was something similar that I preferred where you still define the category and instead create commands by referencing the category within the key name, though in retrospect this may be long and less explicit:

[category.General]
description = "General commands"

[category.General.say]
description = "Make me say anything!"
category = "General" 

I'm wondering if valuing explicitness would help here or if we could instead let TOML implicitly handle these cases - thinking about certain, awful-to-diagnose bugs that may appear in the future.

Thoughts so far?

[LeoCx1000]

The second approach does look better, but I think it would be a bit cumbersome when trying to re-order commands. It's also a bit limiting since any command that you define could overwrite an existing key and cause conflicts.

For example:

[caregory.General]
description = 'General commands.'

[category.General.description]  # Borks
description = "Gives a description of the bot's features"

Same applies for defining sub-commands in this way. The more we expand configurability, the more command names we have to disallow.

I also think that it would be good if we generated a pre-made config off of the code. Although this may require work like subclassing commands.Command and the @command() decorator to add keys like suggested_parent=...

[cyrus01337]

I agree, so the first approach would definitely be the way to go from here.

Config generation wouldn't be a bad idea given how cogs are already loaded, I think a simpler approach for generating it would be to use pathlib instead unless there is something I am overlooking.

[cyrus01337]

@LeoCx1000 What are your thoughts on this?

Also as a side-note, I setup a webhook for Github -> Discord and am only pinging to test it lol

[LeoCx1000]

I think that we're good to go for now with this basic config implementation idea, and can start working on the actual impl. Then we can revisit this issue if we find issues with the impl that need discussion