submodules error

[somenxavier]

Hi,

I have one main program called a.py which has import gestor.models, gestor.environment. gestor.models and gestor.environment are python files in the directory called gestor.

When I run pdoc a.py I get:

pdoc a.py --all-submodules
Traceback (most recent call last):
  File "/usr/bin/pdoc", line 458, in <module>
    module = imp.load_source('__pdoc_file_module__', fp, f)
  File "/usr/lib/python3.5/imp.py", line 172, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 693, in _load
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 662, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/home/xan/SYNC/cc-ng/ng2/a.py", line 4, in <module>
    import gestor.models, gestor.environment
ImportError: No module named 'gestor'

No problem when I run pdoc gestor/environment for example.

What can I do?

[BurntSushi]

Not sure. pdoc is using Python's standard interface to import modules, so you might need to do a little debugging. You might also try fiddling with PYTHONPATH to add gestor to your sys.path.

[jasonb-vbt]

This was my issue as well, except that "." was the directory it couldn't find. When I set PYTHONPATH explicitly to "." plus the previous output of print sys.path, then it works fine. However, it was very counterintuitive that pdoc didn't automatically find associated modules in the same (and current!) directory as the input module. As a suggestion, you might have pdoc explicitly search the current directory--or just add the current directory to sys.path--before throwing the submodule name over to imp.load_source.

[somenxavier]

For me it's a requeriment issue for using that.

[BurntSushi]

I was able to reproduce the problem.

[andrew@Serval ~] virtualenv3 /tmp/pdoc
Using base prefix '/usr'
New python executable in /tmp/pdoc/bin/python3
Also creating executable in /tmp/pdoc/bin/python
Installing setuptools, pip, wheel...done.
[andrew@Serval ~] . /tmp/pdoc/bin/activate
(pdoc) [andrew@Serval ~] pip install pdoc
(pdoc) [andrew@Serval ~] mkdir /tmp/issue90
(pdoc) [andrew@Serval ~] cd /tmp/issue90/
(pdoc) [andrew@Serval issue90] touch a.py
(pdoc) [andrew@Serval issue90] mkdir gestor
(pdoc) [andrew@Serval issue90] touch gestor/{__init__.py,models.py,environment.py}
(pdoc) [andrew@Serval issue90] pdoc a.py
Module a
--------
(pdoc) [andrew@Serval issue90] pdoc a.py --all-submodules
Module a
--------
(pdoc) [andrew@Serval issue90] cat > a.py <<EOF
> import gestor.models
> import gestor.environment
> EOF
(pdoc) [andrew@Serval issue90] python a.py
(pdoc) [andrew@Serval issue90] pdoc a.py
Traceback (most recent call last):
  File "/tmp/pdoc/bin/pdoc", line 472, in <module>
    module = imp.load_source('__pdoc_file_module__', fp, f)
  File "/tmp/pdoc/lib/python3.5/imp.py", line 172, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 693, in _load
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 665, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/tmp/issue90/a.py", line 1, in <module>
    import gestor.models

As far as I can see, this isn't a problem with pdoc, and is an artifact of Python import semantics. pdoc is meant to run with idiomatic Python primarily because the alternative is a neverending list of hacks for patching how Python loads modules. Modifying sys.path for example is something that I never want to do, because it seems like something that could lead to even more obscure or hard-to-debug errors.

In particular, if you insist on documenting a project that isn't idiomatic Python, then you can use existing tools in the Python ecosystem for hacking the import process. For example, this works:

(pdoc) [andrew@Serval issue90] PYTHONPATH=. pdoc a.py
Module a
--------

[jasonb-vbt]

Modifying sys.path for example is something that I never want to do, because it seems like something that could lead to even more obscure or hard-to-debug errors.

That is a valid point. However, as this issue seems to be tripping people up, it should at the very least be documented. I will send you a pull request.