I'm not sure if this is a Click issue or a pdoc3 issue. It came up when running pdoc3 against our CLI project using Click 7. Figured I'd report the issue to both projects just in case.
Assuming we have a python package with one module containing the code below:
import click
def testdeco(func):
def wrapper(x):
print('in deco')
func(x)
return wrapper
@click.command()
@click.option('-s', '--some-arg', 'somearg')
def somefunc(somearg):
"""some func docstring"""
print('foo')
@testdeco
def decofunc(n):
print(n)
def otherfunc():
"""other func docstring"""
print('bar')
I'd expect pdoc3 to generate relevant docs for somefunc()

Click==7.0
Mako==1.1.1
Markdown==3.2.1
MarkupSafe==1.1.1
pdoc3==0.7.4
Relevant comment from pdoc3 devs:
But I'm afraid the proposed solution won't work as click's decorators don't set
__wrapped__(as is customary for decorators) via functools.update_wrapper() nor via functools.wraps(). Instead they only set__doc__manually
https://github.com/pdoc3/pdoc/issues/166#issuecomment-587871751
A PR that uses update_wrapper or wraps in decorators seems fine. I'm not sure if there's a reason it's not used right now, so seeing how it affects things in a PR would be the first step.
Not sure what I was thinking before, but I don't think this will change. The decorators don't produce functions, they produce Command objects. If you need to access the original function you can use somefunc.callback. While the most common type of decorator usually returns a modified or wrapped function, where functools.wraps is appropriate, there is no requirement that a decorator do so, and Click takes advantage of that.
There are tools like sphinx-click that allow Sphinx to understand Click commands. You'll probably need something similar for pdoc.