Replies: 6 comments
-
You committing the lockfile will make no difference at all to the users of your library, who will consume your library via pypi. The metadata on pypi is derived from the requirements in pyproject.toml. |
Beta Was this translation helpful? Give feedback.
-
Thanks, @dimbleby . That makes sense. For us library developers, I think it still makes sense to keep the lockfile for the sake of reproducibility. Is there something else I'm missing? |
Beta Was this translation helpful? Give feedback.
-
keeping the lockfile locally is a trade-off: it's true that you get reproducibility, but it also means that if some new dependency has been released that breaks things for consumers of your library, you're likely to be the last to find out about it. I guess either choice is legit, but the usual advice is for libraries not to commit lockfiles. eg here's Rust saying the same thing about Cargo.lock https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries |
Beta Was this translation helpful? Give feedback.
-
Thanks for the Cargo docs reference. That helps a lot because the Cargo.lock file plays the same role. Your comment, though, is the one that changes my mind:
For my project I had suggested periodically explicitly updating versions declared in the lock file and in the pre-commit config (another place to specify build dependencies). But now it seems that by discarding the lockfile, I can get that behavior automatically at least for the lock file. Thanks for your help. How can we adapt your comment for the Poetry documentation? |
Beta Was this translation helpful? Give feedback.
-
You'll see that Poetry does the same thing, incidentally -- we commit our lock files in both poetry-core (consumed as a library only) and Poetry (an application installed with normal version constraints). It keeps our CI reproducible/prevents random changes in other projects from blocking development, but we still have to refresh our lock file regularly and stay up-to-date to make sure we don't break suddenly for users. It's a balancing act, and that's a hard nuance to capture, but contributions are certainly welcome if you want to try to summarize these thoughts for the docs. |
Beta Was this translation helpful? Give feedback.
-
Thanks @neersighted . It sounds like one way or another periodic maintenance is required to stay on top of breaking changes. Either you can periodically update the lock file, or you can periodically rerun the CI with whatever the latest versions are on the day. Maybe there are other solutions, but I don't want to veer off-topic. A short discussion of why you might want to omit the lock file would improve the docs. It can summarize the points raised in this issue. I'll attempt a couple of paragraphs and submit a PR. |
Beta Was this translation helpful? Give feedback.
-
poetry/docs/basic-usage.md
Line 231 in 2c610de
Why not?
The preceding paragraph basically says committing the lock file makes it easier to reproduce the same experience for all users of the code.
Why would it be different for libraries?
The botocove package uses Poetry to manage its dependencies. botocove is a library for querying AWS, intended to be used in scripts. We are now wondering whether to keep the lock file or not.
Beta Was this translation helpful? Give feedback.
All reactions