regression : pdoc3 doesn't handle current dir anymore

[magowiz]

Expected Behavior

Since one of last updates I was generating documentation of my software using command: pdoc --html . -o documentation --force because I have one module in current directory and a lib package inside current directory that contains modules. Expected Behavior is to get able to generate/update documentation using the above command.

Actual Behavior

as you can see now it claims about option --html not recognized, I was able to reproduce the same issue in a venv and in a docker image based on python:3.8 `pdoc --html . -o documentation --force /usr/local/lib/python3.8/site-packages/docx/section.py:7: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working from collections import Sequence /usr/local/lib/python3.8/site-packages/pdoc/init.py:708: UserWarning: Couldn't read PEP-224 variable docstrings from <Module '****.tests'>: could not get source code m = Module(import_module(fullname), usage: pdoc [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: pdoc --help [cmd1 cmd2 ...] or: pdoc --help-commands or: pdoc cmd --help

error: option --html not recognized`

Steps to Reproduce

1. create project with a module inside root and other modules inside a subfolder/package
2. pdoc --html . -o documentation --force

Additional info

• pdoc version: 0.9.2

[magowiz]

It turns out that the problem is the setup.py file I included in project root to automate packaging, it happens also with original setup.py from example packaging project : pypa sampleproject setup.py. I don't know if you can still consider it an issue or not, anyway, is there any method to exclude files?

EDIT: I found a way to ignore setup.py from current path, I added in init.py :

__pdoc__ = {}
[...]
__pdoc__['setup'] = False

[kernc]

So, can this issue be considered a duplicate of https://github.com/pdoc3/pdoc/issues/180?

[magowiz]

So, can this issue be considered a duplicate of #180?

Yes, I think so, in #180 there are also workarounds that make unnecessary to ignore setup module