python - 从子模块导入 Python 包时避免 pylint 投诉

Question

背景

我有一个 Python 应用程序依赖于作为 git 子模块提供的另一个包，产生类似于以下的目录结构:

foo/
    bar/
        bar/
            __init__.py
            eggs.py
        test/
        setup.py
    foo/
        __init__.py
        ham.py
    main.py

访问 foo 包非常简单，因为 main.py 是从顶层 foo/ 目录执行的；但是 bar 包嵌套在另一个 bar 目录中，不能直接导入。

这很容易解决，通过修改 main.py 开头的 sys.path:

import sys

# Or sys.path.append()
sys.path.insert(0, './bar')

from bar.eggs import Eggs
from foo.ham import Ham

(注意:此代码示例假定 main.py 将始终从 foo/ 调用；如果不是这种情况，' .bar' 可以替换为 os.path.join(os.path.dirname(__file__), 'bar') 尽管这显然更加笨拙。)

问题

不幸的是，pylint 不喜欢这种解决方案。虽然代码有效，但 linter 将 sys.path 修改视为结束“模块顶部”的代码块，并给出了不需要的 wrong-import-position警告:

C: 6, 0: Import "from bar.eggs import Eggs" should be placed at the top of the module (wrong-import-position)
C: 7, 0: Import "from foo.ham import Ham" should be placed at the top of the module (wrong-import-position)

---

类似问题

Adding a path to sys.path in python and pylint

这个提问者有一个问题，pylint 无法完全正确解析导入。这个问题的唯一答案是添加到 pylint 的内部路径；这无法避免对交错的 sys.path 修改的提示。

Answer 1

配置pylint

禁用 .pylintrc 中的 wrong-import-position 检查器是最简单的解决方案，但会丢弃有效警告。

更好的解决方案是告诉 pylint 忽略这些导入的 wrong-import-position，内联。误报导入可以嵌套在启用-禁用 block 中，而不会在其他地方丢失任何覆盖范围:

import sys

sys.path.insert(0, './bar')

#pylint: disable=wrong-import-position

from bar.eggs import Eggs
from foo.ham import Ham

#pylint: enable=wrong-import-position

Ham()

# Still caught
import something_else

但是，如果 .pylintrc 中的 wrong-import-order 被禁用，这确实有一点点时髦的缺点。

---

避免修改 sys.path

有时不需要的 linting 警告源于错误地开始处理问题。我想出了很多方法来避免首先修改 sys.path，尽管它们不适用于我自己的情况。

也许最直接的方法是修改 PYTHONPATH 以包含子模块目录。然而，这必须在每次调用应用程序时指定，或者在系统/用户级别进行修改，这可能会损害其他进程。该变量可以在包装 shell 或批处理脚本中设置，但这需要进一步的环境假设或限制对 Python 调用的更改。

一个更现代、更少麻烦的模拟是在虚拟环境中安装应用程序，并简单地将子模块路径添加到虚拟环境中。

再深入一点，如果子模块包含 setuptools setup.py，则可以简单地安装它，完全避免路径自定义。这可以通过维护对存储库的发布来实现，例如 pypi(专有包的非启动器)或通过利用/滥用 pip install -e 直接或从其存储库安装子模块包。再一次，虚拟环境通过避免潜在的跨应用程序冲突和权限问题使该解决方案更简单。

如果目标操作系统集可以限制为那些具有强大符号链接(symbolic link)支持的操作系统(实际上这排除了至少 10 个以上的所有 Windows)，则可以链接子模块以绕过包装目录并将目标包直接放入工作中目录:

foo/
    bar/ --> bar_src/bar
    bar_src/
        bar/
            __init__.py
            eggs.py
        test/
        setup.py
    foo/
        __init__.py
        ham.py
    main.py

这会限制应用程序的潜在用户并使 foo 目录充满困惑，但在某些情况下可能是一个可接受的解决方案。