hash mismatch error when a wheel has been uploaded to same version since the last lock about poetry HOT 7 CLOSED

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.

from poetry.

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.

from poetry.

I ran into this with python-crontab 2.6.0 and got it fixed by doing poetry lock --no-update --no-cache, which took 10+ minutes, but if I knew that I could clear the cache for a single package now (I'd only skimmed this thread and didn't spot the mention of a plan to add that command), it would've been quicker.

(Leaving this comment here in hopes that it's helpful for other people encountering the same issue)

from poetry.

Actually, it may be a little more convoluted, I'm not really sure pytest-dev/pluggy#134

but i think the takeaway may be the same: poetry should probably be including the filename (or even full URL that was downloaded) in the lock file, so it can consider that when comparing hashes

from poetry.

I don't think they "tampered" with a previous release - they did not modify any existing files, and PyPI does disallow that, as I understand it. They did two things:

1. added .whls to releases that only had .tar.gz
2. deleted a universal wheel and added two other wheels (py2 and py3)

so no existing file was replaced with different content. This is why I think poetry should keep track of the original filename: if downloading a different file, it doesn't make sense to compare to the same old hash.

As for what you said about the "file downloaded on my machine might be different from the one downloaded on someone else's", doesn't that mean that poetry would break if a .lock file is shared between e.g. a Windows and a Linux machine?

from poetry.

As a follow-up to the linked Pygments issue, which sent us maintainers scrambling to figure out what is wrong with our project, only to discover this issue:

Since it's apparently been decided that this is not worth fixing, let me just suggest here to change the error message to include a note that recently added distribution files with the same version can also trigger this.

from poetry.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from poetry.