

新闻资讯
技术学院Python项目结构混乱导致导入报错、测试失败、打包异常的根本原因在于模块路径机制:sys.path未正确包含包路径,__init__.py仅声明包身份而不解决发现路径问题;应使用python -m mypackage.main启动、src布局配合pyproject.toml配置packages,并通过pip install -e .确保可导入。
这标题看着像课程宣传,实际想解决的很可能是:Python项目结构到底该怎么组织才合理?为什么有的项目跑不起来、导入报错、测试写不了、打包还失败?
答案不在“第558讲”,而在你当前项目的 init.py 是否真被需要、setup.py 或 pyproject.toml 里声明的入口是否匹配、以及 sys.path 有没有被手动污染。
根本原因不是代码写错了,而是 Python 解释器根本没把你的包目录当成可导入路径。
os.getcwd())自动加入 sys.path[0],但子目录不会自动递归识别为包__init__.py 文件只是告诉 Python “这个目录可以当包用”,但它不解决“解释器能不能找到它”的问题python mypackage/main.py 运行,my_package 不在 sys.path 里,自然导不进去python -m mypackage.main 启动 —— 此时 Python 会把当前目录当作顶层包路径project/ ├── pyproject.toml ├── src/ │ └── mypackage/ │ ├── __init__.py │ ├── core.py │ └── cli.py └── tests/
更稳妥的结构是把源码放在 src/ 下,再通过 pyproject.toml 配置 packages = [{include = "mypackage", from = "src"}]。这样安装或开发安装(pip install -e .)后,mypackage 才真正成为可导入模块。
现在主流是 setuptools + build,但配置项稍有不慎就会导致包安装后找不到模块。
[build-system] 写法,尤其注意 requires 和 build-backend 必须匹配build-backend = "setuptools.build_meta",对应 requires = ["setuptools>=45", "wheel"]
src/ 结构,必须加 [project] 下的 packages 或 package-dir 声明,否则 pip install -e . 会静默跳过你的包import mypackage; print(mypackage.__file__),路径应该指向 site-packages 下的链接或拷贝,而不是你本地的 src 目录本质还是路径和导入机制问题,不是 pytest 本身的问题。
test_*.py 或 *_test.py,但不会自动把 src/ 加进 sys.path
tests/test_core.py,而代码在 src/mypackage/core.py,pytest 运行时无法直接 import mypackage
pip install -e . 先安装开发版(最可靠)pytest.ini,配 pythonpath = src(仅限 pytest 7.0+,且不推荐用于 CI)conftest.py 的作用域:它只对同级及子目录下的测试文件生效;跨目录共享需靠 pytest_plugins 显式声明入口函数没被正确注册,或者打包时没包含。
console_scripts 是 entry_points 里的一个 key,值格式是 "cmdname = package.module:func",冒号前后不能多空格、不能写错大小写func 是一个可调用对象(函数),且不要带括号,比如写成 main() 就会报错.whl 文件,检查 my_package-*.dist-info/entry_points.txt 是否有对应条目python script.py 测试命令行逻辑,要用 pip install -e . 后直接敲 cmdname,否则路径和入口加载机制完全不同真正卡住人的,从来不是语法,而是“Python 到底在哪个时刻、根据什么规则、从哪几个路径里找模块”。搞清 sys.path 的构成时机、-m 和直接执行的区别、以及 pip install -e . 实际做了什么,比背一百个目录模板都管用。