ocaml
Command to display current lockdir solution
Desired Behavior
With dune pkg lock the solution is printed to the console and the lock directory is in the source tree so it is easy for the user to see what is part of the lock dir and which versions of packages are picked.
However, when the solver is run as a rule, it is silent (rightfully so). The downside however is that it is unclear which packages were selected as the lock directory is in an internal location in the build directory.
It would be nice to be able to print the current solution (if there is one).
Example
$ dune describe pkg solution
Solution for dune.lock:
- base-unix.base
- fmt.0.9.0
- ocaml.5.2.0
- ocaml-base-compiler.5.2.0
- ocaml-config.3
- ocamlbuild.0.15.0+dune
- ocamlfind.1.9.6+dune
- topkg.1.0.7
It's seems awkward to print something with "the current solution", but we could print the solution for something that would just run the solving step again. If everything is already run this should be fast. Once we have the solution, we can print it the same way dune pkg lock does.
The problem is that it doesn't show you the current contents of the lock dir, but then only what would be locked if you locked it again. That's somewhat different semantics, especially if the last build was months ago and dune describe pkg solution would be run now. Also, that command would require network access.
The issue however is that there is no lock directory as far as the user is concerned. The fact that we use a lock directory in autolocking is rather an implementation detail. If the user has not specified the hash of the opam repository then every access will require network access.
If users don't want network access, they can pick a hash for the opam repo. That way the dune describe pkg solution command would pick whatever dune build would have picked in the same place.
Generally if a user is concerned with the versions of the packages they are using staying the same, then they should be using lock directories instead.
If we change the implementation of how autolocking works, then this proposed semantics for dune describe pkg solution would fail on older dune build layouts also.
I therefore think its easier and more correct to just run the rule, like we do for other describe commands.
Generally if a user is concerned with the versions of the packages they are using staying the same, then they should be using lock directories instead.
Yeah, but that's not what I am asking for. I am looking for a feedback mechanism so the user can have an idea what packages get locked. Sometimes you want to make sure that what you defined is getting correctly applied.
Possibly the command is a wrong approach because I agree with you that if I dune build && dune describe pkg solution and then follow up with dune build I have no warranty that the second dune build will not compute a different solution.
Maybe the solution to have insight what is happening is to write the solution into _build/log? That way it doesn't spam users but it can still be used to debug builds.
I wonder if we can ground this more solidly in end-user needs? Because I don't think the way this is heading is very responsive to what, IMO, is the pretty obvious end use case.
One use case (the most obvious, IMO), it just trying to figure out what version of a package is installed.
Suppose I am using dune to manage dependencies, but not using a lock (i.e., dependencies may be updated whenever the project is build cleanly, just so long as they match the declared version constraints). Now, suppose I have dependencies installed consistent with my dependency constraints, and this includes a dependency on (p (>= 1.0). I am naively consulting the documentation for p.1.0, but it is not matching the interface offered by the version of p I have installed. So what is my need here?
Irrespective of implementation details like lock directories, solutions, etc, as I user I want to just know what version of a package I have installed in my current workspace.
How would I do this as using opam? I would
opam info p
But we could also
opam list | rg p
How would I do this using cargo?
cargo install --list | rg p
Another use case is that users may want an account of everything currently installed. Then something like cargo install -list or opam list or uv tree is a good place to look for precedent. It is possible that we can satisfy the first use case just via this second (as does cargo and uv).
if I dune build && dune describe pkg solution and then follow up with dune build I have no warranty that the second dune build will not compute a different solution
IMO, this is yet another good reason why this behavior is obviously bad and not what a user would want! I am over due in opening a separate issue to discuss this. But IMO it is the wrong direction to be ignoring obvious user needs that are easy to meet (in principle) because we have committed to some property which (IMO), is obviously not something a user would want.
