Add dune facilities in the toplevel

[bobot]

Dune specific facilities like dune-build-info, virtual libraries, ... requires specific handling during linking. Dune could provide improved #require facilities in the toplevel using dune-plugin-site (work outside a dune workspace, less scanning, but only use META) or dune-rpc (can give access to local libraries, could use dune-package information).

Such feature should be added step by step, first redo the current #require feature, then ... but at the end the long run would be:

• #require-private to access private library of the current workspace
• Possibility to build the library not yet built
• Virtual libraries handling
• Dune build info
• ocaml (utop) or dune ocaml (resp. dune utop) could be handled differently the first would only access installed information.

It would help for:

• dune-build-info: #5566

[rgrinberg]

One question I have is how do you plan to hide the dune rpc library itself and its dependencies in the repl. For example, dunerpc depends on stdune, is the user going to have Stdune available as an identifier?

[bobot]

I think there is no obligation to add a library in the toplevel scope when it is used by the interpreter.

[rgrinberg]

Could you explain a bit more how would this work? How is #require-private going to communicate with dune? Do you expect that we will build a custom toplevel, or are we going to use #use_output "dune .." to activate the support. If it's the latter, I'm not sure how it's going to work.

[bobot]

The simplest would be to modify upstream utop to add the feature through dune rpc and Topcommon.add_directive. We can also build a custom toplevel that adds the feature. Or allows to load it in the same way ocamlfind was. But I think having first a working version in utop would be the best first step.