feat: %{pkg:foo:lib} pforms for package install layouts

[Alizter]

We make the %{pkg:foo:lib} macros available outside of lock files in dune. This allows users to inspect installed package contents directly. We support all the install sections that we understand in dune.

Depending on such a path automatically introduces dependencies on the package.

This works with ocamlfind packages, dune package management and workspace packages.

The goal is to ultimately hide _build/install as an implementation detail and allow users to properly depend on packages' installed contents without having to inspect them by hand.

• more docs?
• changelog
• fixes Support %{pkg:foo:lib} variables more generally #14193
• fixes Library variable expansion needs a library installed to work #3378

[rgrinberg]

What happens when the package name is invalid?

[Alizter]

Oh yes, this is wrong.

[Alizter]

At the moment we do no validation so it should just say it couldn't find the package.

[rgrinberg]

Thinking about this again, I think this form should take the actual file that it needs as another argument. Otherwise, we need to build everything in the install directory and that is going to cause incredibly inconvenient cycles for folks.

[Alizter]

I think making it be (package foo) is better because then later we can improve that to avoid cycles by materialising install directories with anonymous actions. Having the directory in the form is convenient because it allows users to create paths with it and we don't have to care about supplying the full install tree as syntax.

[rgrinberg]

There are some advantages to both approaches. One advantage of allowing the user to specify a file is that it is actually solving the ticket we've been provided. That is analogous to %{lib:..} which does take a file. Another advantage is that it allows us to refer to installed paths from within the same package and the same section without cycles. There's no way you can workaround this with or without anonymous actions. Finally, it gives us validation to see if the path under the section actually exists.

So in summary, both approaches have their cons. But we should do the direct thing to solve the issue the user is asking for.

By the way, I'm not so hot about allowing the _build/install directory to be reachable via relative paths anymore. I think these paths (whether constructed through an anonymous action or not) should only be accessible through environment variables.