CODEWITHSUNDEEP
pythonpipenv
Michael
Michael

Reputation: 1136

Pipfile.lock version not matching installed package version

I'm using pipenv in a new project I'm working on. Initial pipenv install was Django, with Pipfile showing:

[packages]

django = "*"

and Pipfile.lock showing:

"version": "==1.11.7"

pipenv graph and pip list (from within the pipenv virtualenv) both show that Django version 1.11.7 is installed

However, when I do a subsequent pipenv install new-package the Pipfile.lock is updated to show:

"version": "==2.0"

for Django, even though pipenv graph and pip list both show that version 1.11.7 is still installed locally. This obviously causes problems, as the local Django version is different to that which will be installed in a fresh environment, based on the Pipfile.lock.

It seems like pipenv install new_package is updating the specified version of packages which have already been installed, without updating those packages to the latest version - which seems to be counterintuitive to me. As far as I can see the only way to keep the Pipfile.lock in sync with the local environment would be to either pin all package versions in the Pipfile, or to follow up every pipenv install ... with a pipenv update - neither of which seems to be a particularly intuitive workflow.

I haven't been able to find any documentation or useful answers online which really clarify this behaviour. Is this the expected behaviour, or am I missing something? What is the 'recommended' workflow for handling this situation using pipenv?

Upvotes: 1

Views: 2407

Answers (1)

Michael
Michael

Reputation: 1136

This seems to be a similar/same issue to that described in these pipenv issues. My reading of the responses in the older, issue is that this behaviour is as expected, and that:

  • In order to keep the pipenv generated environment up-to-date with the Pipfile.lock contents a call to pipenv update will be required
  • In order to prevent updates of 'unrelated' packages during a pipenv install new-package it's necessary to pin version in the Pipfile

It would appear from current responses to this issue that there are no immediate plans to change this behaviour.

Upvotes: 1

Related Questions