hash mismatch error when a wheel has been uploaded to same version since the last lock

This is a fun one. My project depends on pluggy = "^.0.6.0" , which up until three days ago only had a .tar.gz release. Then they uploaded some wheels with the same version. I ran a poetry install today, and it seems that it’s preferring the new .whl files (as it should), but then not realizing that this is a different file from the .tar.gz, so it shouldn’t really be comparing to that old hash.

Here’s the error I’m getting:

  - Installing pluggy (0.6.0)

  [VenvCommandError]

  Command ['pip', 'install', '--no-deps', '-r', '/tmp/pluggy-0.6.0iCCMcYreqs.txt'] errored with the following output:

  Collecting pluggy==0.6.0 (from -r /tmp/pluggy-0.6.0iCCMcYreqs.txt (line 1))

    Downloading https://files.pythonhosted.org/packages/82/05/43e3947125a2137cba4746135c75934ceed1863f27e050fc560052104a71/pluggy-0.6.0-py2-none-any.whl

  THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the packag

  e contents carefully; someone may have tampered with them.

      pluggy==0.6.0 from https://files.pythonhosted.org/packages/82/05/43e3947125a2137cba4746135c75934ceed1863f27e050fc560052104a71/pluggy-0.6.0-py2-none-any.whl#sha2

  56=d345c8fe681115900d6da8d048ba67c25df42973bda370783cd58826442dcd7c (from -r /tmp/pluggy-0.6.0iCCMcYreqs.txt (line 1)):

          Expected sha256 7f8ae7f5bdf75671a718d2daf0a64b7885f74510bcd98b1a0bb420eb9a9d0cff

               Got        d345c8fe681115900d6da8d048ba67c25df42973bda370783cd58826442dcd7c

[sdispater]

No, it won’t break. poetry store all the hashes in the lock file, regardless of which platform the wheels are targeted for.

In fact, the lock file stores all the information needed as long as it’s compatible with what has been declared in the pyproject.toml file. This was an early decision to be sure that lock files can be shared between systems and platforms.

In this particular case, since new distributions have been uploaded new hashes are now available. But due to the way poetry caches release information the new hashes are not picked up.

However, I don’t think this warrant changing the dependency resolution process since this is extremely rare and the future cache:clear command will take care of it if it were to happen again.

[sdispater]

Yes I encountered this as well. The maintainers of pluggy reuploaded files and tampered with a previous release (which PyPI should prevent in my opinion) which leads to this error.

poetry caches a lot of information to avoid hitting PyPI each time when resolving dependencies so it won’t be able to pick up the new hashes.

This case is rare, fortunately, so for the time being you can add the new hashes to your pyproject.lock.

That being said, the next 0.9.0 release will introduce a new cache:clear command to clear specific hashes when this occur. This would look like this:

poetry cache:clear pypi:pluggy:0.6.0

And unfortunately your proposal won’t work since the file downloaded on your machine might be different from the one downloaded on someone else’s due to wheels targeted at different systems and platforms. That’s why when poetry downloads files it passes all hashes to check.