Nested workspaces

Dune is built on the concepts of projects and workspaces. Projects now always have a dune-project file, workspaces can be identified by the presence of a dune-workspace file but not always.

Composability is an important feature: putting several projects next to each other in the same workspace make them visible. Various source files are attached to the right project through the hierarchy of dune-project files.

But workspaces are different: they correspond to a closed-world usage of dune where the environment is determined, by opposition to the open-world nature of projects which are to be used in various environments (several versions of the dependencies, etc). So: workspaces are not compositional because they compete as the source of truth.

This brings the question about what we should do when a dune-workspace file is found in the hierarchy in an existing workspace. 2 cases exist, depending on whether the outer workspace is explicit (dune-workspace file where dune is invoked) or implicit (dune-project file with no dune-workspace file where dune is invoked).

It seems that the current behavior is to ignore the file. We could error out, warn, or even ignore the whole subtree in addition.

This can happen when public projects that contain a dune-workspace file are grafted into a monorepo. This is innocuous when installing through opam, and there are valid use cases for a workspace/opam combination (for example, CI uses opam files to get dependency), but it could be worth adding a check on opam-repo-ci if we go that way.

Read the workspace hierarchy handling for dune-project and dune-workspace discovery, focusing on the explicit and implicit outer-workspace cases described here. The issue does not name tests or an entry point; done requires a decided and validated behavior when a nested dune-workspace file is encountered.