我来帮你分析这个问题并给出可行的解决方案：

首先咱们先明确问题场景：你在GitHub上维护了一个用Poetry管理的Python包（没有setup.py，仅靠pyproject.toml指定Poetry作为构建系统），在另一个项目里用poetry add git+https://github.com/blnkoff/foo-project.git安装这个包时，发现虚拟环境里多了个src目录，而用pip install同样的Git地址就不会出现这个情况。你希望Poetry安装时只把包放到venv/lib，不生成venv/src，而且不能只靠单次命令的参数（因为还有其他依赖的GitHub包也不能出现这个问题）。

问题原因 #

Poetry默认有个行为：当安装来自Git仓库的Python包时，如果该包没有预构建的轮子（wheel），它会把Git仓库克隆到虚拟环境的src目录下，在这个目录里完成构建和安装；而pip是在临时目录里完成构建，安装后就清理掉临时文件，不会留下src目录。这个差异是两者安装流程的不同导致的。

解决方案 #

这里有几个不同维度的解决办法，你可以根据自己的需求选择：

1. 修改Poetry全局配置，彻底禁用虚拟环境src目录生成

这个办法一劳永逸，所有通过Poetry安装的Git包都不会再生成venv/src目录，和pip的行为保持一致：

poetry config virtualenvs.src false

这个配置会让Poetry在安装Git包时，不再克隆源码到虚拟环境的src目录，而是像pip一样使用临时目录构建后安装。

2. 确保目标包的pyproject.toml配置正确

如果你的GitHub包的包结构不是src布局（也就是包直接放在仓库根目录，不是src/foo_project这种结构），一定要在pyproject.toml里正确声明包的位置，避免Poetry误判：

[tool.poetry]
# 其他配置（名称、版本等）...
packages = [{ include = "foo_project" }]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

正确的packages配置能让Poetry准确识别包的位置，减少不必要的源码克隆操作。

3. 安装时指定使用pip作为安装器

如果你不想修改全局配置，也可以在单次安装命令里指定让Poetry调用pip来安装这个包，这样就会和直接用pip安装的效果一致：

poetry add git+https://github.com/blnkoff/foo-project.git --installer pip

不过这个办法需要每次安装Git包时都加参数，适合临时需求，如果你有很多依赖的Git包，还是推荐用第一个全局配置的办法。

备注：内容来源于stack exchange，提问作者blnk.off