pipenv: pipenv install --deploy now fails after having worked for months
Issue
pipenv install --deploy now fails in my docker build step due to out of date lockfile.
However whenever I run pipenv lock, it fails to update the hash and instead spits out the original hash that it already was.
Expected
I expect the dependencies to install, as they have been for almost 6 months with no issue.
Actual result
✔ Successfully created virtual environment!
Virtualenv location: /root/.local/share/virtualenvs/-x-v5uFv0
Your Pipfile.lock (ab547e) is out of date. Expected: (9d352e).
Usage: pipenv install [OPTIONS] [PACKAGES]...
ERROR:: Aborting deploy
Steps to replicate
- RUN pipenv install --deploy (in a Docker build step, having copied in the Pipfile and Pipfile.lock)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 22 (13 by maintainers)
Sorry for those issues folks –
pipenv==2022.10.10has been released which includes the fix for the Pipfile hash changing, and also the fix for the metadata writing to the lock file at the end of the lock phase.@Nick-Yazdani the hash generation changed back to how it was before – you may need to re-lock again to get back to that point.
@Nick-Yazdani I opened a PR that I think addresses the issue – the fix is to always re-write the meta section of the generated lockfile dictionary, prior to writing it to the file. I am not sure how it ever worked in the prior implementation, but I don’t imagine this causing many other issues (though one test is failing with this change). Will run through test suite and think through it some more, if possible will cut a new release tomorrow.
@matteius I can’t get it to break now even on the latest (it installs perfectly and so does sync option), I think the issue was that for some reason when I ran pipenv lock with the newest release it wasn’t actually updating the hash as evidenced by the output being the same out of date hash that it began with.
When I downgraded to the previous release and ran pipenv lock, it successfully updated the hash and thus now has resolved the problem.
@Nick-Yazdani Ah wow, thank you for your report – somehow in your example lock file, re-locking it doesn’t update the hash. This is definitely going to be related to the named categories work, there were a number of places I had to refactor how the lock file was accessed and updated, so I am sure that this is it. Thanks for your help in pin-pointing the issue.