Poetry does not add all hashes for multiple constraint dependences

[intgr]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Linux, win32
• Poetry version: 1.2.0
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/intgr/efc96c44c3919189c3757275f0239eb6

Issue

The same example as in #6327. If package to be installed depends on the OS:

python-ldap = [
  { platform = "linux", version = "3.4.0" },
  { platform = "win32", url = "https://download.lfd.uci.edu/pythonlibs/archived/python_ldap-3.4.0-cp310-cp310-win_amd64.whl" },
]

Running poetry lock on Linux only adds hashes for the Linux version of the package. poetry.lock only contains:

python-ldap = [
    {file = "python-ldap-3.4.0.tar.gz", hash = "sha256:60464c8fc25e71e0fd40449a24eae482dcd0fb7fcf823e7de627a6525b3e0d12"},
]

And this is despite the fact that on Linux, poetry lock every time re-downloads the Windows package again.

Resolving dependencies... Downloading https://download.lfd.uci.edu/pythonlibs/archived/python_ldap-3.4.0-cp310-cp310-win_amd64.whl   9%

Using this lockfile, poetry install on Windows causes the following error (note, this has different version numbers, I don't have Windows myself to reproduce cleanly)

 • Updating python-ldap (3.3.1 .../AppData/Local/pypoetry/Cache/artifacts/df/70f0/b890a4118f494cdc75350af78a5bd590e52b9edd2788ca3e01001d1ef1/python_ldap-3.3.1-cp310-cp310-win_amd64.whl -> 3.3.1 .../python_ldap-3.3.1-cp310-cp310-win_amd64.whl)

 RuntimeError
 Hash for python-ldap (3.3.1 http://.../python_ldap-3.3.1-cp310-cp310-win_amd64.whl) from archive python_ldap-3.3.1-cp310-cp310-win_amd64.whl not found in known hashes (was: sha256:a2822da1c27d6d15d2d3a7ccfda4f156810ab525acb5895d56e00611ae4c50f7)

 at ...\lib\site-packages\poetry\installation\executor.py:670 in _validate_archive_hash
      666│         archive_hash: str = "sha256:" + file_dep.hash()
      667│         known_hashes = {f["hash"] for f in package.files}                     
      668│                                                                               
      669│         if archive_hash not in known_hashes:                                  
    → 670│             raise RuntimeError(                                               
      671│                 f"Hash for {package} from archive {archive.name} not found in"
      672│                 f" known hashes (was: {archive_hash})"                        
      673│             )
      674│

I believe this is a regression in Poetry 1.2.0. It seems 1.1.14 simply ignored the missing hash on Windows, but 1.2 is stricter and fails because of it.

[intgr]

As a work-around, it seems manually editing poetry.lock to add the hash solves the problem: poetry lock does not remove it, and the install succeeds on Windows.

[dimbleby]

poetry has never stored hashes for url dependencies, and I don't think this is a regression.

poetry goes "if I have any hashes for this package, then this file had better match one of them". But since it only stored hashes for the non-url package (which has always been the case), that fails.

I haven't tried to reproduce so may be misreading: but so far as I can see this code was much the same at earlier releases, here's 1.1.15

poetry/poetry/installation/executor.py

Line 616 in 46bf7fd

if package.files:

[intgr]

poetry has never stored hashes for url dependencies

I didn't claim Poetry stored hashes for url dependencies in ealier versions.

The issue is: why does it expect to find a hash for this particular url dependency if it doesn't store them?

[dimbleby]

I don't know how to answer your question without just saying what I already said so here goes:

poetry goes "if I have any hashes for this package, then this file had better match one of them". But since it only stored hashes for the non-url package (which has always been the case), that fails.

[radoering]

Actually, just another effect of the same bug as #6327. Thus, same fix.

As already mentioned the missing hashes are not a regression, but the failing installation is a regression.

[github-actions]

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.