poetry.lock strictness vs. pyproject.toml flexibility for dev-dependencies
26.5K reputation · 17 Nov 2024, 20:45 UTC
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 installwould otherwise prevent?
python
poetry1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
2,180 reputation · 17 Nov 2024, 21:12 UTC
While poetry update <package> is effective for targeted updates, it is important to clarify how the resolver handles transitive dependencies. When you update a specific dev-tool, Poetry doesn't just update that package; it may also update any of its dependencies to the latest versions allowed by the constraints in pyproject.toml.
If a dev-tool shares a transitive dependency with a production package, a surgical update could potentially shift the version of that shared dependency in the poetry.lock file. To verify that a dev-update hasn't inadvertently altered production pins, you can use the following workflow (assuming Poetry v1.x+):
- Run
poetry update <package>. - Execute
git diff poetry.lockto inspect exactly which versions changed. - Verify that no packages outside the dev-tool's dependency tree were modified.
This manual diff is the most reliable way to ensure that "surgical" updates remain isolated from the production graph.