我应该分别提交.lock文件更改吗?我应该为提交消息写些什么? [英] Should I commit .lock file changes separately? What should I write for the commit message?

问题描述

我将诗歌用于我的Python包管理器，但是我相信这将适用于任何编程实践.

I'm using poetry for my Python package manager but I believe this would apply to any programming practices.

我一直在做这件事，却不知道我到底在做什么，或者我应该怎么做.

I've been doing this without knowing exactly what I'm doing, or how I should be doing.

在使用程序包管理器并安装新程序包时，通常会进行 .lock 文件更改，以保持确定性.

When you use a package manager and install a new package, there's usually a .lock file change to keep your build deterministic.

通常，我会做出如下更改:

Usually, I would commit these changes like:

$ git add poetry.lock pyproject.toml 
$ git commit -m "Install packages: beautifulsoup4"

即，每次安装/删除软件包时，我都会提交一次.我这样做是因为我觉得应该做的事，但是如果这实际上是处理此问题的正确方法，我将获得0条线索.

i.e, I make a commit every time I install/remove a package. I do it because I FEEL like this is what I should do, but I have 0 clue if this is actually a correct way to handle this.

我做得好吗?或是否有其他任何特定的约定&我应该遵守哪些规则以使其尽可能遵循最佳实践?

Am I doing great? or is there any other specific convention & rules I should abide by to make it follow the best practices as close as possible?

推荐答案

The official recommendation of the poetry maintainers is to commit the lockfile if you develop a deployable application (as opposed to a library).

话虽如此，我的个人经验是不必向VCS提交锁定文件. pyproject.toml 文件是正确的构建说明的参考，而锁文件是一次成功的部署的参考.现在，我不知道 poetry.lock 的规范是什么，但是在与同事合作期间，我经常受到他们的反感，因为只有删除它们才能解决问题.

That being said, my personal experience has been that it isn't necessary to commit lockfiles to VCS. The pyproject.toml file is the reference for correct build instructions, and the lockfile is the reference for a single successful deployment. Now, I don't know what the spec for poetry.lock is, but I had them backfire on me often enough during collaboration with colleagues in ways where only deleting them would fix the problem.

一个常见的问题是，使用不同的操作系统或python版本会导致不同的锁文件，而这种情况不会奏效.我很乐意让我们的CI生成并保留一个权威的引用锁定文件以启用重新生成功能，但是它仍然不会提交到存储库中.

A usual problem was that using different operation systems or python versions would lead to different lockfiles, and that just doesn't fly. I'll gladly let our CI build and persist an authoritative reference-lockfile to enable re-builds, but it still wouldn't be committed to the repository.

如果在您的工作流程中维护共享锁文件是可行的-太好了！您可以避免流水线中的步骤，无需担心的工件，并且可以大大减少构建时间(即使是中型项目也可能需要几分钟才能完成完整的依赖项解析).

If maintaining a shared lockfile is viable given your workflow - great! You avoid a step in your pipeline, have one less artifact to worry about, and cut down dramatically on build time (even a medium-size project can take minutes to do a full dependency-resolution).

但就目前的最佳做法而言，我会考虑将 poetry.lock 添加到 .gitignore 一种比您更好的 做法这样做，并且在添加依赖项时仅提交 pyproject.toml 更改.

But as far as best practices go, I'd consider adding poetry.lock to the .gitignore a better practice than what you do, and only commit pyproject.toml changes when you add dependencies.

这篇关于我应该分别提交.lock文件更改吗?我应该为提交消息写些什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！