pipenv: Any package requiring importlib-metadata breaks locking
The most recent version of importlib-metadata is 2.0.0. This is the version that gets resolved when any package is installed that required importlib-metadata without an upper bound. For example: flake8.
The virtualenv library requires importlib-metadata < 2.0.
When project.get_environment() is called the dependencies for virtualenv are compared to the working set resolved for the Pipfile dependencies and a VersonConflict error is raised.
This is a very frustrating error because doing pipenv lock -v gives no indication of which package requires importlib-metadata < 2.0. Also inspecting pipenv graph gives no indication either.
A temporary fix would be to pin importlib-metadata == "1.7.0" in the Pipfile.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 46
- Comments: 19 (1 by maintainers)
Commits related to this issue
- dependencies: fix version for `importlib-metadata` * Fixes version for `importlib-metadata` to a smaller version than 2.0 to avoid an error when deploying to clusters. See https://github.com/pypa/pip... — committed to rero/sonar by deleted user 4 years ago
- Correct the Pipfile content and update packages - We added only the necessary packages in the Pipfile (there were more packages added there by mistake). We had to pin the flake8 package because of t... — committed to KAUTH/grades-report by KAUTH 2 years ago
- Correct the Pipfile content and update packages - We added only the necessary packages in the Pipfile (there were more packages added there by mistake). We had to pin the flake8 package because of t... — committed to KAUTH/grades-report by KAUTH 2 years ago
- Reproduction Attempt: Bug Fixes and Improvements Commit Series 13 Update README.md: Installation Guidelines 1. Added change to correct directory for installation 2. While running installation guidel... — committed to fusion-jena/computational-reproducibility-pmc by Sheeba-Samuel a year ago
With
pip install -U pipenvwas solved for me.The workaround of deleting the
Pipfile.lockfile and then re-runningpipenv lockalways seems to work but here is what I did for a more permanent fix.pipenv --rmbrew uninstall pipenvpip install -U virtualenvpip install --user pipenvpipenv installRepeat runs of
pipenv lockwork as expected and do not re-trigger the conflict error message.With
importlib-metadata3.0.0 this error seems to be occurring again, even after having the latest version of virtualenvAny suggestions on what we could do to avoid this? @joshsleeper
I found that my issue was actually just matter of updating to the newest
virtualenvpatch release20.0.32once that version was released and incorporated into my lockfiles everything worked like a charm on both python 3.7 and 3.8.
This issue is fixed by the newest release of
virtualenvAny newcomers to this issue should upgrade the version of
virtualenvHere are my debugging notes. Still not sure which package is causing the problem, but this does seem to fix it.
The error you get when you first run
pipenv installwith pipenv version2020.8.13.If you run
pip install -U pipenvit seems to change theimportlib-metadataversion:Now if you run
pipenv install -d --skip-lockit will finish. It seems like a library is requiring a version>= importlib-metadata 2.0.When I pinned the following dependencies it didn’t work at first when running
pipenv lock, however, if I removed the lock file (rm Pipenv.lock) then it worked when I ranpipenv lockagain.@nicofuchsg if you’re implying that simply running the latest version of
pipenvsolves the problem, fyi that’s not the case universally.I encountered this issue using
pipenv 2020.8.13from start to finish.How about if we are using pip instead of virtualenv.
The sequence of calls causing this error are fairly elaborate.
If this search results in finding no version of the package installed, then there is no error.
However, if there is only a version of the package that conflicts with virtualenv’s requirements installed then the error discussed above is thrown.
So to see this specific error you would likely need to fall under the following conditions:
Without fully understanding the logic of adding pipenv to the project environment, it is hard to know the right point at which to address this issue.
However, it would seem that the dependency check for pipenv should use the version of python which will be used to run pipenv. Then an error would reflect a real problem, rather than the current situation.
Alternatively, error handling around adding pipenv to the environment could handle VersionConflict errors. Either silently, which would assume that pipenv was correctly installed with its dependencies, but that might obviate the point of adding it to the environment. Or perhaps by installing required dependencies for pipenv for the project version of python.
I wonder if there are plans for the
pipenvto use the new built-inpipdependency resolver.pip uninstall -y importlib-metadataand runpipenv lockagain work for me.Following @scuerda comment it works for me to fix
importlib-metadata 3.0.0with last pipenv version, hope it helps