使用Poetry管理Python依赖的最佳实践及GitHub自动更新方案合理性验证

作为常年用Poetry和GitHub Actions维护项目的开发者，我得说你的思路完全站得住脚！

你提到的用GitHub Action自动执行poetry update、在新分支提交变更并自动创建PR的方案，确实是一种非常直接且可控的依赖更新方式，完全可以替代Dependabot或Renovate这类工具，理由如下：

• 完全贴合Poetry的原生工作流：直接用Poetry官方的update命令，避免了第三方工具和Poetry之间可能出现的兼容性问题
• 高度可控：你可以自定义Action的触发时机（比如每周定时运行、或者监听特定事件），还能在PR里直接看到依赖更新的完整变更，方便团队review后再合并
• 减少工具依赖：不用额外配置Dependabot/Renovate的规则，降低了项目的工具复杂度

至于你担心的这个方案是否属于最佳实践——我觉得在很多场景下它确实是最优解，尤其是当你已经熟悉Poetry的命令，且不想引入额外工具的时候。

你提到的Poetry和Dependabot搭配不顺畅的问题我也深有体会，两者在锁文件处理、版本解析逻辑上确实存在一些冲突，目前也没有特别完美的解决办法，所以放弃Dependabot转而用原生的Poetry命令+GitHub Action的方式，反而能避免很多不必要的麻烦。

当然，如果你后续需要更精细化的更新控制（比如只更新特定类型的依赖、忽略某些版本），也可以在Action里给poetry update加上参数，或者结合脚本做更复杂的逻辑，灵活性非常高。

备注：内容来源于stack exchange，提问作者rcardinaux