-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The case for removing poetry.lock? #2835
Comments
Note, I found this thread on the poetry issue tracker that describes the issue with content-hash, describing why it happens, and potential work-arounds. |
What benefits do we currently gain from having the lockfile, besides ensuring a successful poetry install after cloning the repo? Option b) does sound appealing due to less maintenance overhead. For removing lockfile Any other considerations for option b)? |
Keep in 7.x, remove in 8.x after tidy up of pyproject.toml min versions |
just putting my thoughts on this here - An argument in favor of the lock file is it means that every dependency is exactly specified for CI runs, For people using rdflib as an application, then it is likely that they only get the locked dependencies if they are doing a
To achieve this in another project, I added a CI job that is basically
This goes a long way to ensuring that the lockfile is always correct in |
There are also a number of pre-commit hooks supplied by |
We've been seeing increasingly often situations where CI Jobs for PRs are failing because the
poetry.lock
file is out of sync with thepyproject.toml
file, or where there is a hash conflict in thepoetry.lock
file. These are usually caused by dependabot updating only thepyproject.toml
and not thepoetry.lock
file (though it is supposed to do both), or dependabot generating an invalidpoetry.lock
file, that happens sometimes.There are lots of other ways it can get out of sync, including:
poetry update
to bump the lockfile before creating their PRmain
into an old PR before merging the PRDocumentation about this on from Poetry:
And also from the Poetry docs:
Again this comes down to the old question, is RDFLib an application or a library? If it is an application, we want everyone who contributes to RDFlib to be using exactly the same dependency versions, and producing exactly the same builds, and we need to build RDFLib in a reproducible way.
If RDFlib is a library, then we can simply include a compatibility-range of dependency versions in the pyproject.toml file, and it is up to the end-user's package management tool to install the right versions that work with the final application.
Personally I only ever use RDFLib as a library. All of my applications, even small scripts, have their own dependency list and start with
import rdflib
. To me that makes RDFLib a library. But I know there are others who use RDFLib only for the built-in cli tools. So to them, RDFLib is an application.See this Stackoverflow Answer for a well thought out response to this same issue: https://stackoverflow.com/a/61076546
And also this comment from the stackoverflow answer:
Its now 2024 and it seems people (inlcuding us) are facing the same issue.
This is an argument from that thread in favor of keeping the lockfile:
So we need to either
a) find a way to always keep everyone using the same lockfile, keep the lockfile up to date in
main
for every PR including dependabot PRs, and probably even ensure all contributors and all CI environments are using the same version of poetry.or
b) remove the lockfile from the repo.
The text was updated successfully, but these errors were encountered: