Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Pipenv lock fails to resolve dependencies

See original GitHub issue

Be sure to check the existing issues, both open and closed.

Running pipenv lock fails to resolve the dependencies and generate a Pipfile.lock, producing the error listed below.

Running pipenv install --skip-lock works fine and as the output below shows pipenv has tried the version (3.0.0b7) that matches the requirement. There is no other dependency on marshmallow. Also pipenv install runs fine if the virtualenv is first removed with pipenv --rm.

Describe your environment
  1. OS Type - Ubuntu 17.10
  2. Python version: 3.6.2
  3. Pipenv version: 11.0.2
Expected result

A Pipfile.lock is generated

Actual result
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches marshmallow>=3.0.0b7
Tried: 0.1.0, 0.1.0, 0.2.0, 0.2.0, 0.2.1, 0.2.1, 0.3.0, 0.3.0, 0.3.1, 0.3.1, 0.4.0, 0.4.0, 0.4.1, 0.4.1, 0.5.0, 0.5.0, 0.5.1, 0.5.1, 0.5.2, 0.5.2, 0.5.3, 0.5.3, 0.5.4, 0.5.4, 0.5.5, 0.5.5, 0.6.0, 0.6.0, 0.7.0, 0.7.0, 1.0.0a0, 1.0.0a0, 1.0.0, 1.0.0, 1.0.1, 1.0.1, 1.1.0, 1.1.0, 1.2.0, 1.2.0, 1.2.1, 1.2.1, 1.2.2, 1.2.2, 1.2.3, 1.2.3, 1.2.4, 1.2.4, 1.2.5, 1.2.5, 1.2.6, 1.2.6, 2.0.0a1, 2.0.0a1, 2.0.0b1, 2.0.0b1, 2.0.0b2, 2.0.0b2, 2.0.0b3, 2.0.0b3, 2.0.0b4, 2.0.0b4, 2.0.0b5, 2.0.0b5, 2.0.0rc1, 2.0.0rc1, 2.0.0rc2, 2.0.0rc2, 2.0.0, 2.0.0, 2.1.0, 2.1.0, 2.1.1, 2.1.1, 2.1.2, 2.1.2, 2.1.3, 2.1.3, 2.2.0, 2.2.0, 2.2.1, 2.2.1, 2.3.0, 2.3.0, 2.4.0, 2.4.0, 2.4.1, 2.4.1, 2.4.2, 2.4.2, 2.5.0, 2.5.0, 2.6.0, 2.6.0, 2.6.1, 2.6.1, 2.7.0, 2.7.0, 2.7.1, 2.7.2, 2.7.2, 2.7.3, 2.7.3, 2.8.0, 2.8.0, 2.9.0, 2.9.0, 2.9.1, 2.9.1, 2.10.0, 2.10.0, 2.10.1, 2.10.1, 2.10.2, 2.10.2, 2.10.3, 2.10.3, 2.10.4, 2.10.4, 2.10.5, 2.10.5, 2.11.0, 2.11.0, 2.11.1, 2.11.1, 2.12.0, 2.12.0, 2.12.1, 2.12.1, 2.12.2, 2.12.2, 2.13.0, 2.13.0, 2.13.1, 2.13.1, 2.13.2, 2.13.2, 2.13.3, 2.13.3, 2.13.4, 2.13.4, 2.13.5, 2.13.5, 2.13.6, 2.13.6, 2.14.0, 2.14.0, 2.15.0, 2.15.0, 3.0.0a1, 3.0.0a1, 3.0.0b1, 3.0.0b1, 3.0.0b2, 3.0.0b2, 3.0.0b3, 3.0.0b3, 3.0.0b4, 3.0.0b4, 3.0.0b5, 3.0.0b5, 3.0.0b6, 3.0.0b6, 3.0.0b7, 3.0.0b7

This used to work with the 10.0.0 release and started failing after upgrading to 11.0.2.

Steps to replicate

I have attached the Pipfile, verbose output from the pipenv lock, and the output from pipenv graph:


Unpack the file and run pipenv install pipenv lock

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:14 (1 by maintainers)

github_iconTop GitHub Comments

BillKGcommented, Dec 24, 2018

I managed to fix this by deleting the package from the Pipfile manually by removing the package under [packages] and then run pipenv install package-name again.

mvincerxcommented, Feb 25, 2021

I struggled with this one for a while. Then I found what I believe is the root cause of the failure. I decided to switch over to pipenv after pipreqs failed on my system due to other Python3.8 upgrades.

I ran these commands with an existing requirements.txt file present in working dir: python3 -m pipenv install [This worked fine] python3 -m pipenv lock [This failed. And the resolution path given in stdout was not helpful, IMHO]

I decided to look at how my existing requirements.txt was parsed and imported in the Pipfile. As it turns out, I believe there may be a parsing error in pipenv, which might be easily resolved.

So I opened my Pipfile, and I noticed that whereas some dependencies used a general syntax, like so:

simple-term-menu = "*"
prompt-toolkit = "*"

Other packages (which apparently were parsed by pipenv) retained the original == like so:

Sphinx = "==3.0.3"
Pygments = "==2.2.0"

Of course, the above syntax didn’t look correct to me. So I corrected the syntax, removing the redundant == like so:

Sphinx = "3.0.3"
Pygments = "2.2.0"

Then I re-ran the command: python3 -m pipenv lock

And finally, pipenv created a Pipfile.lock successfully.

I hope this helps someone else who converts to using pipenv and plans to use an existing requirements.txt.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to fix locking failed in pipenv?
Just delete the Pipfile.lock then rerun pipenv lock .
Read more >
Common Pipenv Errors and How to Solve Them
The second most common reason locking fails is that we attempt to install a package that is a pre-release version. You can resolve...
Read more >
Frequently Encountered Pipenv Problems - Read the Docs
☤ An exception is raised during Locking dependencies…​​ Run pipenv lock --clear and try again. The lock sequence caches results to speed up...
Read more >
You likely have a mismatch in your sub-dependencies. First try clearing your dependency cache with $ pipenv lock --clear, then try the original...
Read more >
pipenv Documentation
Pipenv uses two files to do this: Pipfile and Pipfile.lock (which will look ... Will create a virtual env and install dependencies (if...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found