Elr*_*ond 3 python pkg-resources
我们的主应用程序有一些额外的功能,用户可以启用。这些功能在它们自己的目录中。这些功能可能需要额外的依赖项。我正在考虑将它们放在requires.txt那里的文件中。在运行时,我们想让人们知道该功能是否会中断。我目前正在考虑这样的事情:
def checkfeature(feature):
everything_okay = True
f = pkg_resources.resource_stream(feature, "requires.txt")
with f:
for r in pkg_resources.parse_requirements(f):
if pkg_resources.working_set.find(r) is None:
print "%r not found, please install, otherwise this feature does not work" % (r,)
everything_okay = False
return everything_okay
Run Code Online (Sandbox Code Playgroud)
这是正确的,pythonic 的做事方式吗?这有意义吗?
小更新:为什么如此复杂,而不是try: import ... except ImportError: ...像一个答案中所建议的那样:
pkg_resources无论如何使用的测试。所以这就是我上面的想法使用 pkg_resources 的原因。can_we_unit_test_this_plugin(plugin)功能使事情变得更容易。第二次更新:extra_requireinsetup.py呢?
setup.py加载。但这确实是下一步。extra_requirerequires.txt通常,您只需尝试导入依赖项,并ImportError优雅地处理异常:
try:
import dependency
except ImportError:
# dependency missing, issue a warning
import warnings
warnings.warn('dependency not found, please install to enable xyz feature')
Run Code Online (Sandbox Code Playgroud)
您可以在extras_require基于 setuptools 的setup.py脚本的条目中列出此类依赖项。pip,easy_install并且zc.buildout所有人都可以处理安装此类附加功能。请参阅声明“Extras”(具有自己的依赖项的可选功能)。
extras_require如果您有这些要求,您可以使用该条目列出最低版本要求。是的,用户可能已经安装了旧版本的依赖项;我只是清楚地记录了要求。真的,测试功能,而不是版本。如果您因为添加了某个 API 方法而需要更新版本?测试该方法而不是版本。
但是,它听起来好像你可能要打包的插件作为独立的软件包,而不是,然后列出那些在extras_require。我会使用入口点来注册和枚举这样的插件。你就这样不需要检验的进口或用于包装,你只是枚举注册入口点来代替。每个插件都列出了自己的依赖项并拥有自己的单元测试。
| 归档时间: |
|
| 查看次数: |
2100 次 |
| 最近记录: |