为项目构建 epydoc 文件时需要 KeyError 帮助
我有一个 pylons 项目,其中包含一组广泛的功能测试,我希望我的手动 QA 能够不时阅读这些测试,因此我使用 epydoc 在功能测试模块上构建 html pydocs。
看起来工作正常。它生成文档,我可以在没有任何明显问题的情况下浏览它们。
但是,当我运行 epydoc 构建时,我收到一个奇怪的错误,并且我不确定如何修复它:
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| In project.tests.functional.resource:
| Import failed (but source code parsing was successful).
| Error: KeyError: '__file__' (line 28)
|
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| In /Eclipse/product/project/server/src/project/tests/functional/resource/ftest_module1.py:
| Import failed (but source code parsing was successful).
| Error: KeyError: '__file__' (line 28)
|
+------------------------------------------------------------------------------------------
总共有 2 个包和 8 个模块发生了这种情况。我一开始认为,可能是模块头部或包的 __init__ 中缺少文档字符串,但添加它们并没有解决问题。
以下是专门为功能测试编写的 epydoc 配置文件的副本:
[epydoc]
modules: project.tests.functional.resource,project.tests.functional.views
output: html
sourcecode: yes
#graph: none
target: ../pydoc/ftests
name: PROJECT
# exclude: test
private: no
imports: no
verbosity: 0
include-log: yes
这是用于执行它的 shell 脚本的副本:
#!/usr/bin/env bash
basedir=${0%/*}
cd "$basedir/../src"
etc="../etc"
pydoc="../pydoc"
pydoc_ftests="../pydoc/ftests"
mkdir -p $pydoc
mkdir -p $pydoc_ftests
epydoc -v --config $etc/epydoc.config
epydoc -v --config $etc/epydoc.ftests.config
有什么建议吗?
I have a pylons project with an extensive set of functional tests that I want my manual QA's to be able to read from time to time, so I'm using epydoc to build out the html pydocs on the functional test modules.
It seems to be working fine. It generates the docs, and I can navigate through them without any apparent problems.
However, I'm getting a strange error when I run the epydoc build, and I'm not sure how to fix it:
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| In project.tests.functional.resource:
| Import failed (but source code parsing was successful).
| Error: KeyError: '__file__' (line 28)
|
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| In /Eclipse/product/project/server/src/project/tests/functional/resource/ftest_module1.py:
| Import failed (but source code parsing was successful).
| Error: KeyError: '__file__' (line 28)
|
+------------------------------------------------------------------------------------------
There are a total of 2 packages and 8 modules on which this is happening. I thought at first, it might be the absence of docstrings at the head of the modules, or in the __init__ of the packages, but adding them did not fix it.
Here is a copy of the epydoc config file written specifically for the function tests:
[epydoc]
modules: project.tests.functional.resource,project.tests.functional.views
output: html
sourcecode: yes
#graph: none
target: ../pydoc/ftests
name: PROJECT
# exclude: test
private: no
imports: no
verbosity: 0
include-log: yes
And here is a copy of the shell script used to execute it:
#!/usr/bin/env bash
basedir=${0%/*}
cd "$basedir/../src"
etc="../etc"
pydoc="../pydoc"
pydoc_ftests="../pydoc/ftests"
mkdir -p $pydoc
mkdir -p $pydoc_ftests
epydoc -v --config $etc/epydoc.config
epydoc -v --config $etc/epydoc.ftests.config
Any suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
最后,我所做的只是在 epydoc 命令中包含 --parse-only ,以强制它不导入任何内容(从而解决了无法定位导入的问题,但根本没有真正回答为什么会发生这种情况)。这不是一个完美的解决方案,但它满足了要求......
What I ended up doing, finally, was just including --parse-only on the epydoc command, to force it not to import anything (thus working around the problem of unlocatable imports, but not really answering why it was happening at all). Not a perfect solution, but it satisfied the requirements...