pkg: enable upgrading particular packages in a lock

[shonfeder]

Currently, the only way to update dependencies when using a lock with dune package management is to resolve and update the entire lock. But users will sometimes want to update just some subset of packages (see, e.g., quantifyearth/container-image#7 (review)).

This would be equivalent to a command such as uv lock --upgrade-package <package> from uv.

[rgrinberg]

I don't think this is possible with our design, we can only run the solver to produce the entire solution, and we do not look at existing solutions when solving.

We do have adequate workarounds though. Constraints are the preferred way to drive the solver, and we can already write those in the dune-project or dune-workspace file. This is already enough to upgrade any package. To preserve the old solution as much as possible, we can set the versioning policy to prefer the smallest available version of a package.

[Alizter]

One solution we discussed with @gridbugs is for the current lock file to be printed as a bunch of constraints for the packages / opam repo. If users can run a command to get this output easily, they can put it in their workspace / project file and tweak the versions they want by hand.

Same goes for the opam repository hash which would be a sensible way to deal with the offline mode discussion.

[shonfeder]

I don't think this is possible with our design

Is there a fundamental reason we cannot improve the design to support this? It seems many other tools manage it.

[rgrinberg]

Other tools have different limitations. Our limitation stems from the our solver being stateless and therefore not being able to refer to a previous solution to produce a new one. So all we're left with are various ways to emulate upgrades with varying trade-offs.

[gridbugs]

Is this really not possible? Assuming the semantics of upgrading a package are to change its version to the latest version which is co-installable with the locked versions of all the other dependencies, it seems like Dune could craft a suitable constraint problem for the solver which guarantees that the only difference between the lockdir before and after solving is that the package in question now might have a higher version. Of course this solution isn't guaranteed to upgrade the package to its latest version if doing so would require changing the versions of other locked packages, but if we allow it to upgrade other packages too then we're no longer just upgrading a particular package any more anyway.