Python：在一系列脚本之间共享通用代码

Posted 2023-02-23

【中文标题】Python：在一系列脚本之间共享通用代码

【英文标题】：Python: sharing common code among a family of scripts

【发布时间】：2013-08-07 20:52:10

【问题描述】：

我正在一个项目中编写一系列 Python 脚本；每个脚本都在项目的子目录中，如下所示：

projectroot
  |
  |- subproject1
  |    |
  |    |- script1.main.py
  |    `- script1.merger.py
  |
  |- subproject2
  |    |
  |    |- script2.main.py
  |    |- script2.matcher.py
  |    `- script2.merger.py
  |
  `- subproject3
       |
       |- script3.main.py
       |- script3.converter.py
       |- script3.matcher.py
       `- script3.merger.py

现在几个脚本共享一些代码。共享代码最好被认为是项目本身的一部分，而不是我会单独编译并从中制作一个库或放入站点范围的 PYTHONPATH 的东西。我可以将该代码放在不同的地方，比如projectroot 目录本身，或者projectroot 的子目录common（也许）。

但是，到目前为止，我想到的大多数方法都涉及使用空 __init__.py 文件从我的子项目中制作包并使用相对导入（或在每个子项目中冗余地弄乱sys.path。更糟糕的是，这似乎是在构建围绕这一系列脚本的包结构与来自被拒绝的PEP-3122 的以下警告相冲突：

注意！此 PEP 已被拒绝。 Guido 将包中运行的脚本视为反模式。

如果包中的脚本是反模式的，我该如何设置以将公共代码保留在同一个项目中？或者这里可以接受基于模块和包的系统吗？哪种方法最干净？ （FWIW 我宁愿在项目根目录中有一个诸如 shared.py 或 common.py 之类的文件，而不是创建一个与“真实”子项目同级的实用程序目录。）

【问题讨论】：

我相信 django 使用集中入口点 manage.py 来运行它的所有脚本。这样做可以让您将subprojectX 转换为包，并在“manage.py”（入口点）脚本中集中处理导入。作为包，我相信它会很容易地支持common 模块，您的共享功能可以在其中存在。

我认为应该是 PEP-3122，而不是 PEP-32122。

【参考方案1】：

我建议将琐碎的“启动器”脚本放在项目的顶层，并将每个子项目文件夹放入包中。包中的模块可以相互导入，也可以将公共代码分解到common 包中。

如果我们假设各种merger 模块可以重构为共享版本，那么结构如下所示：

projectroot
  |- script1.py # launcher scripts, see below for example code
  |- script2.py
  |- script3.py
  |
  |- common
  |    |- __init__.py
  |    |- merger.py # from other packages, use from ..common import merger to get this
  |
  |- subproject1
  |    |- __init__.py # this can be empty
  |    |- script1_main.py
  |
  |- subproject2
  |    |- __init__.py
  |    |- script2_main.py
  |    |- script2_matcher.py
  |
  |- subproject3
       |- __init__.py
       |- script3_main.py
       |- script3_converter.py
       |- script3_matcher.py

启动器脚本可以非常简单：

from subproject1 import script1_main

if __name__ == "__main__":
    script1_main.main()

也就是说，它所做的只是导入适当的“scriptN_main”模块并在其中运行一个函数。使用简单的脚本也可能对脚本启动速度有一些小好处，因为main 模块可以将其编译后的字节码缓存到.pyc 文件中，而脚本永远不会被缓存。

注意：我重命名了您的模块，将 _ 字符替换为 . 字符。标识符（例如模块名称）中不能有 .，因为 Python 期望它指示属性访问。这意味着这些模块永远无法导入。 （我猜这只是示例文件的产物，而不是您在真实代码中拥有的东西。）

【讨论】：

看起来不错，但我可以在 subproject1.script1_main.py 内部说什么来访问 common？我尝试了import common，但收到了File "movie/main.py", line 1, in <module> import common ImportError: No module named common，我不想手动设置sys.path。我错过了什么吗？

我认为import ..common 应该可以工作（明确的相对导入）。确保您在顶层运行脚本，而不是直接运行子项目文件，否则它可能没有意识到它在一个包中（在这种情况下，您将收到关于导入的 .. 部分的错误)。

1. “common”目录需要在里面有一个__init__.py 文件。 2.命令import ..common，而from .. import common是正确的。它要求 projectroot 还包含__init__.py 并且也像父包一样被导入。 3.如果你不导入projectroot但是你在里面运行了一个脚本，那么你可以轻松import common，因为'.'脚本目录会在启动时自动添加到 python 路径中。

呃。我看不到这样做的更好 方式，所以+1，但尽管如此，这太可怕了。如果我有一大套所有共享代码的命令行脚本，我该死的希望能够用一个合理的目录结构来组织它们。 Python 强迫我以这种方式做事（或诉诸使用 PYTHONPATH）有点令人沮丧。

添加 docker、构建脚本和文档使这个结构变得丑陋

【参考方案2】：

我的偏好是单独的“bin”或“scripts”目录，子项目作为库/包：

projectroot
  |
  |- scripts
  |
  |- lib
  |    |
  |    `- matcher.py
  |    `- merger.py
  |    `- subproject1
  |    `- subproject2
  |    `- subproject3

你的脚本可以像通常的包一样引用任何必要的子项目。您的子项目也可以通过导入相互引用。

如果有帮助，您还可以拥有一个主脚本或共享脚本来为您设置子项目包。

【讨论】：

我确实喜欢这种划分，但我已经编辑了我的答案，以说明将每个脚本放在单独的子项目中的原因——这是因为每个“脚本”都有多个部分。我想要一些共享库代码——不同子项目中的每个脚本都可以使用的函数（和类）。

我认为共享代码应该放在库的根目录中。请查看我的编辑。

Matt - 如何在scripts 下的脚本中从lib 导入任何内容？您将无法使用相对导入，因为它们在技术上不是模块。

【参考方案3】：

我最近发现了这种技术，它似乎适用于 Python 3.9。这与 Blckknght 的答案差别不大，但它避免了为 projectroot 本身中的每个子项目运行脚本的需要。

projectroot
  |
  |- common
  |    |
  |    `- merger.py
  |
  |- subproject1
  |    |
  |    `- __main__.py
  |
  |- subproject2
  |    |
  |    |- __main__.py
  |    `- matcher.py

从projectroot 目录，运行

python -m subproject1

python -m subproject2

实际上，您将subproject1 和subproject2 视为“应用程序包”。

subproject1 和 subproject2 似乎都可以直接import common.merger，无需任何特殊措施，例如破解导入路径。

有一个小故障，可能很重要，也可能不重要。在每个子项目中，导入根目录为 projectroot，因此您必须在项目本身中使用绝对导入或显式相对导入。

import .matcher

或

import subproject2.matcher

但不是

import matcher # ModuleNotFoundError: No module named 'matcher'

另一个缺点是它可能需要不明显的-m 标志来运行应用程序。