The initial venvstacks locking mode operates by way of constraint files: when an upper layer depends on lower layers, the pinned requirements of the lower layers are used as constraints when compiling the requirements for the upper layer.
The key benefit of this approach is that it allows selective relocking of the upper layers, the key downside is that it can lead to resolution failures if the upper layer's dependencies specify a maximum version that is less than the version pinned by the lower layers.
An alternative locking strategy is available by allowing stack definitions to opt out of using uv pip compile to lock each environment individually, and instead use uv's notion of "workspaces" to map each layered environment to a non-package pyproject.toml file in a common workspace anchored on the relevant base runtime environment.
When using this locking mode, selective locking would no longer be available (since the entire workspace shares a single lockfile), but the locking process would have an improved ability to resolve potential conflicts between upper layer and lower layer transitive dependency declarations.
Note that the locking mode to use should be part of the venvstacks.toml stack definition file, rather than being specified on the command line when relocking the project. The initial version of that setting would support two modes, constraints (the default), and comprehensive (the new mode added to implement this feature request).
The initial
venvstackslocking mode operates by way of constraint files: when an upper layer depends on lower layers, the pinned requirements of the lower layers are used as constraints when compiling the requirements for the upper layer.The key benefit of this approach is that it allows selective relocking of the upper layers, the key downside is that it can lead to resolution failures if the upper layer's dependencies specify a maximum version that is less than the version pinned by the lower layers.
An alternative locking strategy is available by allowing stack definitions to opt out of using
uv pip compileto lock each environment individually, and instead useuv's notion of "workspaces" to map each layered environment to a non-packagepyproject.tomlfile in a common workspace anchored on the relevant base runtime environment.When using this locking mode, selective locking would no longer be available (since the entire workspace shares a single lockfile), but the locking process would have an improved ability to resolve potential conflicts between upper layer and lower layer transitive dependency declarations.
Note that the locking mode to use should be part of the
venvstacks.tomlstack definition file, rather than being specified on the command line when relocking the project. The initial version of that setting would support two modes,constraints(the default), andcomprehensive(the new mode added to implement this feature request).