Really? You can put your opam package files and dune files wherever you want and it’ll automagically work. Submodules can be defined far away from the library and it’s fine. If your opam packages are empty it’s fine, dune doesn’t care about versions of packages anyway. If you want to vendor/patch a library, just drop it anywhere in your project. Yet dune seems to be unaware or executables and libraries when you want to run or build something (you need to pass paths).
That's mostly because dune is 'composeable' so it accepts project components anywhere in the tree. But the components themselves are laid out in a certain way:
- A dune file in a specific directory makes that directory a component
- An .ml file in the directory with the same name as the component (in the dune file) becomes the main module of the component
- Any submodules aliased inside the main module are properly wrapped and namespaced.
Sure, but Cargo and go modules/vendors are composable too but there’s still a forced convention that doesn’t allow you to place your files wherever you want.
Oh and, the way name and public_name works is also not great. Basically you never know what is being importer or used because it ultimately depends not on how the folder is named but on either name or public_name in a dune file. For example in rust you can import what’s in folder a/b by doing a::b but in OCaml you import a.b or a_b it it’s what set as name or public_name.
