Pipenv与setup.py工作流问题求助：依赖版本冲突如何解决？

核心问题 #

你当前的矛盾根源是错误地将开发环境的依赖快照（Pipfile.lock）直接固化到了Pkg-1的setup.py中。Pipfile.lock的作用是锁定当前开发/部署环境的精确版本，而setup.py应该声明的是宽松且合理的依赖范围——两者的定位完全不同，强行绑定就会导致后续依赖冲突无法自动解析。

具体解决建议 #

1. 修正setup.py的依赖声明逻辑 #

停止用pipenv-setup同步Pipfile.lock的固定版本，改为同步Pipfile中packages部分的宽松依赖约束：

• 若pipenv-setup支持仅同步Pipfile的参数（比如--pipfile-only类的选项），直接启用该参数生成setup.py；
• 若工具不支持，手动维护setup.py里的install_requires，只保留类似A>=3、C<=3.5这类范围约束，不要写死具体版本号。

2. 安装新依赖的正确流程 #

当给Pkg-1新增依赖C时，按以下步骤操作：

• 在Pkg-1目录下执行pipenv install C，让pipenv自动解析依赖冲突，生成符合所有约束的新Pipfile和Pipfile.lock（此时B会被锁定在3.5版本，同时满足A>=3和C<=3.5）；
• 更新Pkg-1的setup.py，仅添加C的宽松依赖约束（比如C<=3.5），不要固定B的版本；
• 提交更新到GitHub后，在Pkg-2中重新执行pipenv install ssh://git@github.com/user/Pkg1.git，此时pipenv会在Pkg-2的环境中重新解析所有依赖，自动适配出兼容的版本组合。

3. 跨开发包的更优依赖方式 #

既然Pkg-1和Pkg-2都是你正在开发的包，完全没必要通过GitHub安装，直接用本地可编辑模式更高效：
在Pkg-2的目录下执行：

pipenv install -e ../path/to/Pkg-1

这种方式下，两个包的依赖会由Pkg-2的pipenv统一管理，Pipfile.lock会包含所有包的兼容版本，彻底避免setup.py固定版本带来的冲突问题。

工作流的问题总结 #

你的工作流确实存在认知偏差：

• Pipfile.lock是为了保证当前项目的开发/部署环境一致性，属于“项目内部锁定”；
• setup.py是为了告诉包的使用者“我的包需要哪些依赖，以及它们的版本范围”，属于“对外声明兼容范围”。
  把lock文件的固定版本写到setup.py里，相当于强制所有使用者必须用你开发环境里的 exact 版本，这不仅违背了Python包依赖的设计逻辑，还会频繁引发依赖冲突。

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