The build and lock subcommands should provide a way to request that uv pip compile be called with the --upgrade option when locking.
The current approach to relocking-with-upgrades involves deleting the lock files prior to locking, which is OK when genuinely relocking everything (just delete the entire requirements subfolder), but annoying when using --include to request selective relocking.
As @neilmehta24 pointed out, a simple top level --upgrade option won't do the trick, since a command like python -m venvstacks lock --upgrade --include framework-torch --lock-derived might upgrade an app layer when we don't want it to.
Two potentially viable options would be:
make --upgrade a multi-use list option, like --include, with a pip-style --upgrade :all: option to explicitly opt-in to upgrading every layer that is being relocked.
make the decision on whether or not to eagerly upgrade everything part of the layer spec in venvstacks.toml rather than being something that is configurable on every locking request
The two approaches could also be combined, with venvstacks.toml specifying a default behaviour for each layer, and the CLI allowing that to be overridden for specific invocations.
The
buildandlocksubcommands should provide a way to request thatuv pip compilebe called with the--upgradeoption when locking.The current approach to relocking-with-upgrades involves deleting the lock files prior to locking, which is OK when genuinely relocking everything (just delete the entire
requirementssubfolder), but annoying when using--includeto request selective relocking.As @neilmehta24 pointed out, a simple top level
--upgradeoption won't do the trick, since a command likepython -m venvstacks lock --upgrade --include framework-torch --lock-derivedmight upgrade an app layer when we don't want it to.Two potentially viable options would be:
--upgradea multi-use list option, like--include, with apip-style--upgrade :all:option to explicitly opt-in to upgrading every layer that is being relocked.venvstacks.tomlrather than being something that is configurable on every locking requestThe two approaches could also be combined, with
venvstacks.tomlspecifying a default behaviour for each layer, and the CLI allowing that to be overridden for specific invocations.