我正在一个项目中编写一系列 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
之类的文件,而不是创建一个与“真实”子项目同级的实用程序目录。)
我建议将简单的“启动器”脚本放在项目的顶层,并将每个子项目文件夹放入包中。包中的模块可以相互导入,也可以将通用代码分解到一个
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 希望它指示属性访问。这意味着这些模块永远无法导入。 (我猜测这只是示例文件的产物,而不是您实际代码中的内容。)
我的偏好是单独的“bin”或“scripts”目录,其中子项目作为库/包:
projectroot
|
|- scripts
|
|- lib
| |
| `- matcher.py
| `- merger.py
| `- subproject1
| `- subproject2
| `- subproject3
您的脚本可以像平常的包一样引用任何必要的子项目。并且您的子项目还可以通过导入相互引用。
如果有帮助的话,您还可以使用主脚本或共享脚本来设置子项目包。
我最近发现了这个技术,它似乎适用于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
视为“应用程序包”。
子项目1和子项目2似乎都可以直接
import common.merger
,无需任何特殊措施,例如破解导入路径。
有一个小故障,它可能重要也可能不重要。在每个子项目中,导入根目录是
projectroot
,因此您必须在项目本身内使用绝对导入或显式相对导入。
import .matcher
或
import subproject2.matcher
但不是
import matcher # ModuleNotFoundError: No module named 'matcher'
另一个缺点是它需要可能不明显的
-m
标志来运行应用程序。