test: show that universal libraries can't share the public_name

[anmonteiro]

Inspired by a question from @andreypopp.

This is a bit of a sad limitation, because it means enabled_if just proliferates when depending on installed libraries.

[rgrinberg]

Could you describe the test a bit more here? It should be possible to know what it's about without knowing any context.

[jchavarri]

I talked about this with @andreypopp offline, the problem is that we have been using two contexts in a single opam switch until now. But installing public libs with the same name should be possible if each context was linked to a different opam switch, using st like (context melange (opam (switch x.xx.x))).

[jchavarri]

I tried using (switch) in the melange context defined in the test so that public libraries get installed in separate switches, but the result is the same. 😕 I guess Dune duplication checks come before actually checking if the public libraries are being installed in separate switches?

because it means enabled_if just proliferates when depending on installed libraries.

I fail to see how the premise of this PR would work. How can we avoid the proliferation of enabled_if without something like #10362? As a consumer of a universal library, how can I use it without having two contexts? In reality, a "universal" library consists of two implementations, so I can't imagine a way in which these two implementations are exposed under a single name. For this, Dune already provides a solution: virtual libraries. But they require to hide the implementation details behind abstract types to make it work. Universal libraries allow you to expose the implementations to consumers, at the cost of defining two build contexts.

[anmonteiro]

I guess Dune duplication checks come before actually checking if the public libraries are being installed in separate switches?

Indeed, I believe they're coming from scope.ml, when creating the db from stanzas.

[anmonteiro]

@rgrinberg thanks, I made the description a bit more clear.

[rgrinberg]

It's worth adding a statement on if this is a bug or an intentional limitation.

[anmonteiro]

to be honest, we're not sure. It depends a bit on the usage, and how they're installed:

• for Melange libraries that clash, it's not a problem if they have the same public name, as we install melange artifacts under <lib_name>/melange anyway.
• for other libraries, if we decided to install them in the same context, they would be overwritten.

We're working on an installation RFC with the aim of making a special case for a "melange context" that can be installed in the same prefix as native libraries with the same name.

[rgrinberg]

Okay, well I think this particular issue is easily fixed. We just ignore libraries with enabled_if for the purposes of libname_conflict_map.