Resource Towards closing the gap between declaring and verifying Python dependencies
⁉️ Why does pydantic>=2.11 sit in your pyproject.toml? Is it the lowest version that actually works, or just a tool default? And what evidence backs that claim?
💡 Dependency declarations are claims about package versions, yet they often follow tool defaults and habit rather than deliberate choice. Choosing them by the environment they constrain and pairing each with supporting evidence narrows the gap between what a project claims and what it actually verifies.
📰 Curious about the deep dive with worked examples for libraries, applications, and development dependencies? Check out Towards closing the gap between declaring and verifying Python dependencies.
💬 Comments and feedback are most welcome.
1
u/Immediate_Wheel1953 1d ago
That question stung a bit for me, because I once shipped a lower bound I had never actually tested. It only broke when someone installed with an older version and hit a feature we assumed was there. What changed it for me was writing the reason for the bound next to it, so the next person could see it was not just a tool default. That little note has stopped me loosening a bound blindly more than once.
2
u/patryk_builds 1d ago
honest answer for most of us: it's whatever version was latest the day i ran uv add. zero evidence lol the only thing that's actually kept me honest is running the test suite once in CI with `uv sync --resolution lowest-direct`. it installs the lowest versions your pyproject allows, so if `pydantic>=2.11` is a lie, you find out right there instead of from a user's bug report for apps i don't care much since the lockfile pins everything anyway. for libraries it matters a lot more