mkdocs / mkdocs-click

An MkDocs extension to generate documentation for Click command line applications
https://pypi.org/project/mkdocs-click
Apache License 2.0
109 stars 15 forks source link

Print options in a sleek table format #11

Closed yudai-nkt closed 3 years ago

yudai-nkt commented 3 years ago

Options are currently documented in a plain format as if they were copy-pasted from a terminal emulator. I'd be happy if they are rendered in a human-readable HTML table.

yudai-nkt commented 3 years ago

Thanks for creating mkdocs-click anyway! This package and mkdocstrings leave me no choice but to use Click as an argument parser and makes it possible to make a beautiful documentation for both CLI and Python API.

florimondmanca commented 3 years ago

@yudai-nkt You're welcome! I just realized there had been some contributor activity on this repo :-) Will be taking a look soon!

florimondmanca commented 3 years ago

@yudai-nkt So I've taken a quick look at #12, and that's looking great.

What I'm thinking though is that we might want to let users decide which style they'd like, or at least introduce a table style in a backwards-compatible manner.

I guess what could be feasible would be a new :style: option on the mkdocs-click block, that would toggle which style should be used:

::: mkdocs-click
    :module: example.cli
    :command: main
    :style: table

If we do that, I'd expect the implementation to be purely additive, i.e. the current _make_options() should remain basically untouched, but we'd add a _make_table_options() function and switch between the two in _recursively_make_command_docs().

Makes sense?

yudai-nkt commented 3 years ago

I need to dig into your codebase to find out how the :option: notation works, but your suggestion totally makes sence.

I want to ask two questions before working on this feature:

  1. what should the default (i.e., current style) be named? plain came to my mind but I appreciate it if you have a better option name.
  2. Adding a new parameter style, which can be either table or plain, to _make_options() like this sounds more straight-forward to me rather than defining two functions. May I ask the reason you want purely additive implementation?
def _make_options(ctx, style="plain"):
    if style == "plain":
        # format options here
    elif style == "table":
        # format options here
    else:
        # raise some ValueError
florimondmanca commented 3 years ago

@yudai-nkt :+1: The style=... parameter sounds good, as well as plain.

yudai-nkt commented 3 years ago

25 is ready for your review, @florimondmanca!