[Python] If a Python app uses uv.lock for dependencies, should pyproject.toml include version...

This question is not about dependency management in general. It is about the specific yet very common case of building an application that runs in an isolated environment such as a docker container or dedicated virtualenv, where we have full control over exactly which Python packages are installed.

I am using uv as a package manager, and checking the uv.lock file into version control, so that the application always runs with exactly the same dependency versions. When I want to upgrade a dependency, I use uv to update uv.lock only. (Or I let Dependabot do this for me, now that it supports uv).

My question is, how should I list the dependencies in pyproject.toml?

dependencies = [
"django >= 4.1.14",
"jinja2 >= 3.0.2",
"numpy >= 1.15.3"
]


I could use >= constraints, as shown above. But as new updates are released, the versions in uv.lock will soon diverge from these lower bounds, leaving them to serve as nothing but distracting noise. Why those particular lower bounds? Those probably just happened to be the most current versions at the time I switched from a previous package manager to uv, and have become fossilized here.

dependencies = [
"django",
"jinja2",
"numpy"
]


It seems, then, that it is better to provide no version constraints at all, as shown above. But although this use case should be quite common, I cannot find any reference to it in the uv docs. Indeed, the docs shy away from even admitting that dependencies can be listed in pyproject.toml without version constraints, although the uv tool itself handles this without any complaint.

When the project is not a distributable package, but rather an application over which I have complete control of the environment, is this the best pattern to use for dependencies? Or am I missing something?

Continue reading...