Print All Outdated Packages

[rgrinberg]

Version selection aside, it would be independently useful to know which packages are currently out of date with respect to the opam-repository. I propose that we add a command: dune pkg outdated that would print all immediate dependencies that are out of date. It may also accept a --transitive flag to print all outdated transitive dependencies as well. This command should not modify anything in the workspace.

@Leonidas-from-XIV @gridbugs do you think this will be useful?

[Leonidas-from-XIV]

I agree that it would be useful. Quick question about the semantics however:

If you use a switch, should it use the version installed in the switch? Or should it require the packaging support? I would somewhat prefer the latter, as it is an easier problem to tackle especially with potentially pinned dependencies. But it also makes the command less generally useful.

[tmattio]

Could the command be used to update the lockfile too? If it is exposed in Dune RPC, we could even have a code action in the editors to upgrade the packages to the latest version.

[rgrinberg]

If you use a switch, should it use the version installed in the switch? Or should it require the packaging support? I would somewhat prefer the latter, as it is an easier problem to tackle especially with potentially pinned dependencies. But it also makes the command less generally useful.

Just a reminder that we will make no references to existing opam switches in the released version. So the latest version will be taken from the internally stored opam repository.

Could the command be used to update the lockfile too? If it is exposed in Dune RPC, we could even have a code action in the editors to upgrade the packages to the latest version.

It could, but we first need to define what an "upgrade" is. It might help to remember that we only have this process for updating the build plan:

• Configure version constraints, pass various options to the solver.
• Regenerate the build plan from scratch

In particular, this process cannot refer to the existing build plan. All other high level operations such as upgrades, adding new packages, removing new packages must be imitated by that simple process above. Once we define what an upgrade is, we can add support to it via RPC, cli, etc.

[Alizter]

Do we want to query the repo and print outdated versions or run the solver and print versions that will be updated if locked again?

• The first has the advantage that it is faster, but may give inaccurate information due to solver constraints.
• The second would give accurate information about which packages can actually be upgraded, however would take more time.

[gridbugs]

I can see a use case for both options.

[Alizter]

@gridbugs I've gone for the first as it isn't really up to this command to decide what can actually be upgraded. That's the job of dune pkg lock so there is no point replicating behaviour.