feat: allow arbitrary command classes

[jayceslesar]

Add a new option :command_class that allows a user to specify a custom type for a command class, which will then attempted to be imported. Defaults to click.BaseCommand.

Closes #80

[jayceslesar]

Ah there is more too this because https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L104 looks like a decent amount of those. Do we want to support a special option for each one of those checks?

[jayceslesar]

yeah would need to specify options for the following:

1. command_class (already implemented in existing commits)
2. multicommand_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L104
3. option_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L219
4. choice_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L268
5. datetime_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L274
6. intrange_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L280
7. floatrange_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L280

Seems feasible to just default to all the click ones as a default and use the same pattern that is added so far for command_class ?

[ofek]

After looking closer into https://github.com/python-trio/asyncclick, I'm hesitant to document the feature but I think it's okay if you add options for each of those as long as they are prefixed by something (and again, undocumented). I think that library is fundamentally wrong for literally forking the code rather than wrapping (in which case click objects would work because of subclassing).

I would appreciate feedback from @oprypin as I really think that library got it wrong.

[ofek]

Are you still interested in adding support for other custom classes like Context? I actually require this now as well!

[jayceslesar]

Are you still interested in adding support for other custom classes like Context? I actually require this now as well!

I am! Are you looking at just async-click? I was curious what it would take to add support for:

async-click
argparse

Others??

https://github.com/danimelchor/clypi ?

It no longer remains mkdocs-click in that case but making it easy to support a wide variety of CLI's would be pretty cool

[ofek]

I'm interested in using rich-click but I'm going to open another PR later today that minimally supports arbitrary Command-like, Group-like and Context-like objects which would work for all types of libraries, importantly without configuration because I found out click has a paradigm for that already based on class attributes. My PR would not support the other classes you mentioned like Option so you would probably have to add support in this PR after rebasing.

[ofek]

#82

[ofek]

Okay, the PR is merged so you can go ahead and rebase! The main 3 classes should be supported now.