hash mismatch for local pypi deps

[Abhinav-Upadhya-ni]

Hello all,

When using local wheel files(path = "/absolute/path/pkg.whl") as dependencies in poetry 2.x, the lock/install flow fails with hash mismatch if the wheel is rebuilt after the initial lock.

This worked in poetry 1.8.x, but in 2.x the wheel file's sha256 is pinned into poetry.lock. Any change to wheel(even with same version and filename) causes:

archive_hash = f"{hash_type}:{get_file_hash(archive, hash_type)}"
      792│ 
      793│         if archive_hash not in known_hashes:
    → 794│             raise RuntimeError(
      795│                 f"Hash for {package} from archive {archive.name} not found in"
      796│                 f" known hashes (was: {archive_hash})"
      797│             )

poetry version: 2.1.3

[Abhinav-Upadhya-ni]

What am I missing? Is there a subtlety in how Poetry computes or stores hashes for local wheels, or is there a bug in how Poetry handles local wheel dependencies in custom groups?

[radoering]

If the hash changes, you should relock. The lockfile protects you from someone stealthily swapping the wheel.

[Abhinav-Upadhya-ni]

Ok, that didn't seem to help particularly.
Let me elaborate further.

Setup:

• I have a producer package that builds a wheel and exposes it as a local dependency for a consumer package.
• The consumer’s pyproject.toml references the local wheel using a path in a custom dependency group.

Producer build steps:

• Build the wheel: poetry build
• Clear Poetry cache: poetry cache clear --all -n
• Lock dependencies: poetry lock --no-cache
• Install the runtime group: poetry install --with runtime

Details:

• There is only one wheel file present in the dist directory at all times.
• The wheel is not rebuilt or modified after the lock step.
• The path in pyproject.toml matches the actual wheel location.
• The Poetry cache is cleared after building and before locking/installing.

Problem: Despite this, when I run the install step, Poetry fails with a hash mismatch error for the local wheel, saying the hash is not found in known hashes.
This makes it impossible to reliably use local wheels as dependencies in a multi-stage build, even when following the documented order of operations.

[Abhinav-Upadhya-ni]

Am I missing something here?

[radoering]

I did not verify, but according to your description I assume that the wheel is stored in the artifact cache, which is never cleared.

Background information: Poetry has two types of (persistent) cache: the metadata cache (<cache-dir>/cache) and the artifact cache (<cache-dir>/artifacts). poetry cache clear and --no-cache only influence the metadata cache. There is no command to clear the artifact cache.

The issue is that you rebuild the wheel without changing the version of the package. I think you have several options:

• Change the version of the package if you have to rebuild, e.g. with local version identifiers (poetry build --config-settings local-version=<version>)
• Do not pre-build the wheel, but use a directory dependency instead of a file dependency in the consumer's pyproject.toml so that poetry builds the wheel on the fly. (I am not sure if that works or if changes are ignored if you do not change the version.)
• Write a small script that removes your wheel from the artifact cache.

[Abhinav-Upadhya-ni]

hey thanks, this helped.