We are migrating a large Python monorepo from Poetry 1.1.15 to 2.1.2 (primarily to gain support for URL dependency authentication). This migration has introduced challenges with our lock file management due to stricter hash checking, which wasn't as apparent in the older version.

he repo contains multiple interdependent local packages. Let's say we have packages A, B, C, and D.

• B depends on A
• C depends on A
• D depends on B and C

Our development workflow involves building these local packages into wheel files. These wheels are then referenced in the respective pyproject.toml files using local URLs, possibly via a supplementary source configured to point to a local directory or server where these wheels are placed during setup.

Example pyproject.toml snippet for package B (simplified):

[tool.poetry]
name = "package-b"
version = "0.1.0"
description = ""
authors = ["Your Name <[email protected]>"]

[tool.poetry.dependencies]
python = "~3.10.16"
package-a = { version = "^0", source = "local"

[[tool.poetry.source]]
name = "local"
url = "http://localhost:8008/"
priority = "supplemental"

[tool.poetry.dependencies]
# ... other dependencies
package-a = { version = "0.1.0", source = "local-wheels" } # Referencing via source


[build-system]
requires = ["setuptools", "poetry-core>=2.1.1"]
build-backend = "poetry.core.masonry.api"

Current poetry version used : 2.1.2

(Note: The exact dependency declaration might differ based on whether you use path dependencies during development or point directly to built wheels)

The Problem:

We have multiple developers (let's say User A and User B) working on this repository.

1. User A makes changes (could be dependency changes or just code changes) in packages A, B, C, D. They run poetry build for the changed packages and then poetry lock to update the poetry.lock file, committing both code and the lock file.

2. User B pulls the latest changes. They then make only code changes within, say, package B (no changes to B's dependencies in pyproject.toml).

3. User B pushes their code changes without running poetry lock, assuming it's unnecessary because dependency version's haven't changed.

4. CI Failure: Our Continuous Integration pipeline runs a setup process (e.g., building all local wheels and then running poetry install). This fails with a hash mismatch error. Poetry detects that the hash of the package-b wheel (built in CI from User B's code) does not match the hash recorded in the poetry.lock file (committed by User A).

What We've Considered:

1. Running poetry lock on every push: This works but is undesirable because our repository is large, and running poetry lock takes around 5 minutes, significantly slowing down the development cycle, especially for minor code changes.

2. Removing Hashes from poetry.lock: We tried scripting the removal of hashes specifically for our local packages within the poetry.lock file before committing. However, this breaks our production deployment setup. When we run poetry install --no-dev --only main (or similar production install commands), Poetry throws an error because it expects hashes for packages, especially those defined with URLs/sources.

3. Using Path Dependencies (develop = true): Instead of building/hosting wheels and using URL/source dependencies, we considered using direct path dependencies (e.g., package-a = { path = "../A", develop = true }). However, adopting this would require a significant restructuring of our repository to ensure each local package conforms to the standard structure expected by Poetry for path dependencies to work reliably. This level of refactoring is currently not feasible for us.

Question

Is there a way to configure Poetry or adjust our workflow to handle this scenario more gracefully? Specifically:

• Can we make Poetry less strict about hash checking only for specific local URL/source dependencies, while still enforcing hashes for external dependencies from PyPI?

• Is there a recommended pattern for managing lock files in a monorepo with interdependent, locally built packages where code changes frequently, without incurring the cost of a full poetry lock on every minor change?

• We need a solution that ensures reproducibility (the goal of lock files) but doesn't hinder the development workflow and still allows for a verifiable production installation.

We understand the security and reproducibility benefits of hashes, but the current strictness regarding frequently changing local builds is causing significant friction. Any advice or alternative approaches would be appreciated.