poetry.lock strictness vs. pyproject.toml flexibility for dev-dependencies

When managing a project with Poetry (v1.x+), there is a fundamental tension between ensuring absolute reproducibility in production and maintaining agility during the development phase. The deterministic resolver ensures that poetry install adheres strictly to the poetry.lock file, which prevents version drift across environments.

However, in collaborative development settings, strict adherence to the lock file can hinder the adoption of critical security patches or minor updates for development-only tools unless a full poetry update is performed, which may inadvertently shift other stable dependencies.

The goal is to determine the most stable strategy for updating specific development dependencies without compromising the integrity of the production dependency graph.

• Should developers rely on poetry update <package> to surgically modify the lock file for specific dev-tools?
• Does this approach introduce risks of implicit dependency shifts that poetry install would otherwise prevent?