I'm writing this principally for me to find via Google the next time this happens. Which is to say that the problem occurs relatively frequently but not enough that I can remember how to resolve but instead vaguely remember that it was painful.
tldr: get the file parseable and then run pipenv lock
The essential cause of merge conflicts in the pipenv Lockfile is the package SHA that changes whenever you change a dependency. If dependencies are changing in different branches then you are almost guaranteed to get merge conflicts.
The important thing is that while the git merge markers are in the file pipenv can't run because it needs to parse the lockfile before it does anything else.
It doesn't really matter which merge you choose so assuming your pull is on a tested branch you should be able to use git checkout --theirs Pipfile.lock.
Once the file is parseable you can just run pipenv lock to regenerate the lockfile with the correct combined dependencies.
Assuming there are no version conflicts as a result of the combined dependency requirements you should be done and can commit the newly generated file as the result of the merge.
Top comments (2)
SAME! I had to look this up last week. Do you mind if I mention you in my blog?
Sorry, I missed the notification. No problem.