在Travis中导入GitHub仓库时第二个Python模块导入失败

我之前在CI环境里也碰到过类似的包导入问题，咱们一步步来拆解排查：

你怀疑模块名和仓库名不一致是很合理的，毕竟很多时候仓库名和实际导入的模块名是分开设置的，你可以通过这几个方法验证：

• 查看安装包的实际模块目录：在Travis的构建脚本里添加命令，先找到第二个包的安装位置，再查看site-packages里的实际模块文件夹名：

  # 获取包的安装路径
  PKG_LOCATION=$(pip show repository_test_ii | grep "^Location:" | cut -d' ' -f2)
  # 列出site-packages下的模块目录
  ls $PKG_LOCATION/site-packages/
  

  比如如果输出里是test_ii而不是repository_test_ii，那你导入时就得用import test_ii而不是仓库名。

• 直接读取第二个仓库的setup.py配置：在Travis构建中临时克隆第二个仓库，查看setup.py里的name参数——这才是Python识别的模块名：

  git clone git@github.com/my_account/repository_test_ii.git -b development
  cat repository_test_ii/setup.py | grep -E "name\s*="
  

  比如如果看到name="test_ii"，那导入名就是test_ii，和仓库名无关。

如果模块名没问题，那可以从这些角度继续查：

• 检查Python的sys.path路径：有时候CI环境的虚拟环境配置可能导致安装的包不在Python的搜索路径里。在导入前添加调试命令：

  import sys
  print("Python搜索路径：", sys.path)
  

  对比第二个包的安装位置（用pip show获取）是否在sys.path中。

• 查看详细的安装日志：默认的pip install输出比较简略，你可以改成verbose模式，看第二个包安装时有没有隐藏的警告或错误：

  pip install -v -r requirements.txt
  

  比如可能存在依赖冲突，导致第二个包的某些组件没正确安装，虽然表面上显示“成功”。

• 确认Travis和本地的Python版本一致：如果本地用的是Python 3.8，但Travis配置的是3.10，可能setup.py里的兼容性设置导致安装后无法导入。检查.travis.yml里的python字段，和本地python --version对齐。

• 检查第二个仓库的setup.py配置正确性：比如packages参数是否正确指定了模块目录，比如用find_packages()时有没有漏掉子目录，或者手动指定的包名错误。可以在Travis里尝试editable安装，然后验证导入：

  pip install -e git+ssh://git@github.com/my_account/repository_test_ii.git@development#egg=repo_test_ii
  python -c "import repository_test_ii; print(repository_test_ii.__file__)"
  

  如果导入失败，Python会给出具体的错误信息（比如找不到某个子模块、语法错误等），这比单纯的“No module named”更有参考价值。

• 清理Travis缓存：如果之前的构建缓存了旧的安装包，可能导致新的包没被正确安装。在.travis.yml里添加缓存清理步骤：

  before_install:
    - pip cache purge
  

  或者手动在Travis后台清空项目缓存。

内容的提问来源于stack exchange，提问作者Nathan