Fix: bumps version of requests in Pipfile and Pipfile.lock #99
Conversation
| }, | ||
| "flask-migrate": { | ||
| "hashes": [ | ||
| "sha256:493f9b3795985b9b4915bf3b7d16946697f027b73545384e7d9e3a79f989d2fe", | ||
| "sha256:b709ca8642559c3c5a81a33ab10839fa052177accd5ba821047a99db635255ed" | ||
| "sha256:a25b3d2d2bb0f0724f104afbadae888a4b942e7221b451f720c69698d4863da7", |
There was a problem hiding this comment.
so much for a lock file if all the versions change when one package is upgraded; these do not seem requests dependencies, so they should stay the same? What is happening?
There was a problem hiding this comment.
There is a huge issue here about it: pypa/pipenv#966
Looking at pipenv graph I can't see any dependencies between flask-migrate here and requests. I thought it might be a shared transitive dependency but I still can't find any paths between. I have a feeling the graph output may not be complete.
I think the actual problem is in the Pipfile and this ~=A.B , which means "update 'A.B' to 'A.B.C' as necessary", so there was probably a minor version bump hidden in those hashes somewhere.
There was a problem hiding this comment.
I think @de-code is the pipenv expert here, he might be good enough to investigate for us.
There was a problem hiding this comment.
Not quite sure what I can add. The linked issue seems to describe the behaviour. The docs are a bit muted and could be more explicit. Looks like pipenv devs are looking into this issue. In the interim we could simply update the Pipfile to restrict the versions.
There was a problem hiding this comment.
I've done a little more digging and pipenv has a --selective-upgrade option.
doing this: pipenv install --selective-upgrade requests==2.20 updates requests and it's dependencies, however it's also touching a bunch of other things. Those other things look much less important than flask. I didn't figure out (again) how to revert in git, so I'm just going to open a new branch and a new pr
There was a problem hiding this comment.
Missed that option. But if we know that another dependency is breaking the build, then maybe it might be better to declare the version it in the Pipfile. Otherwise maintaining the problem could become more difficult. I believe that is what we would do if we used a requirements.txt as well (until we can fix the underlying issue if there is one).
There was a problem hiding this comment.
Reverting a git commit: Without the need to to rewrite the history (which shouldn't be necessary with a squash merge later on) it should be simply: git revert <commit> which will create another commit undoing the change.
There was a problem hiding this comment.
Reverting a git commit
I was being facetious - I've learnt how to revert in git at least a dozen times now and been burnt every single time. I think git is an abomination.
No description provided.