dune describe external-lib-deps: printing out more information

[moyodiallo]

Printing out more information, the package in which an external library belongs to, the libraries, executables and tests at this point with their respective external_lib_deps.

It was possible with the command dune external-lib-deps which was removed since dune.3.0, to use @install @runtest aliasis. To get it back, we ended up to not be able to use those (dune describe external-lib-deps), this is why knowing the package of an external library could help.

The goal is to have much information for ocurrent/opam-dune-lint#46.

[emillon]

@moyodiallo 3.7 is due soon - do you want it to include these changes? if so can you rebase, mark this as ready and fix the tests? thanks!
(otherwise postponing to 3.8 is fine too)

[moyodiallo]

I wanted to add the information about the package of an executable that can be installed by the rule (install ...). Like in this description : ocurrent/opam-dune-lint#46 (comment).

I need some suggestion/help how to do that properly, because I want to avoid an extra analysis of dune files.

@emillon

[emillon]

OK, I see. Thanks for the pointer.

First, about the scope of this PR - can we first try to land what is already working, and then extend the behavior to separate (install) in a subsequent PR (that might not make it in 3.7)?

As for the extension to (install): it's not straightforward to do that in the general case. Maybe the following can work:

• extend dune describe workspace to also include info about (install) stanza. Concretely that would be pairs of (source, destination) paths
• in opam-dune-lint, you'd be able to cross reference the sources of installed files with the infos about executables in dune describe workspace - these have some info about their dependencies
  Would that be enough for your use case?

[moyodiallo]

First, about the scope of this PR - can we first try to land what is already working, and then extend the behavior to
separate (install) in a subsequent PR (that might not make it in 3.7)?

Yes sound good.

As for the extension to (install): it's not straightforward to do that in the general case. Maybe the following can work:

• extend dune describe workspace to also include info about (install) stanza. Concretely that would be pairs of (source, destination) paths

Thanks, good proposition, if we can have that without using dune describe workspace because we don't want dune to fail resolving library dependencies. A new command like dune describe installs would be nice.

[emillon]

Thanks!

[esope]

Apologies for not reviewing this PR. I was not able to find enough time.