implicit_transitive_deps false and module shadowing/name conflicts

[yfyf]

I was hoping that implicit_transitive_deps can help prevent conflicts in the top-level namespace when there's a "polluting" transitive dependency, but it seems that it cannot help.

Here's a small example project with a dependency on ocaml-compiler-libs, although this would work with any package, I believe.

$ cat dune
(executable
  (name server)
  (modules server)
  (libraries config ocaml-compiler-libs.common)
)
(library
   (name config)
   (modules config)
)

$ cat server.ml
let () = print_endline Config.foo

$ cat config.ml
let foo = "bar"

$ cat dune-project
(lang dune 3.16)
(implicit_transitive_deps false)

dune build produces the following error:

File "_none_", line 1:
Error: Files .server.eobjs/native/dune__exe__Server.cmx
       and /nix/store/cs8jpkz6cr9r8cjx5r00hkna31r3dvn7-ocaml-5.2.0/lib/ocaml/compiler-libs/ocamlcommon.cmxa
       make inconsistent assumptions over interface Config

This is because ocaml-compiler-libs depends on the "real" compiler-libs, which get included when linking the executable (see attached build.log) and pollute the global namespace with 260+ compiler lib modules.

Is there a way to work-around situations like this? It would be great to somehow "sandbox" the polluting package.

P.S. Interestingly, with implicit_transitive_deps true the error is more cryptic (Unbound value Config.foo), because the module simply gets shadowed.

[rgrinberg]

It's not possible. Your best bet is to just rename your config library

[yfyf]

Thanks for the clarification. But then what is the point of having a package like ocaml-compiler-libs if it still clashes with everything? The README claims that it "repackage(s) the OCaml compiler libraries so they don’t expose everything at toplevel".

[rgrinberg]

I guess if you use this library, you won't have toplevel names like Config polluting the global namespace. Although you still will not be able to use them yourself.