The current behavior may be following the original intention of the maintainers, but it surprises users and wastes their time so it is wrong! If there is a reasonable fix that preserves backward-compatibility and behaves as user expect, it should be applied.
Dune has logic to find the project root. dune init <component>
should look at whether there is a project root. If there is, it can behave as dune add
. If there is not, then there are two choices:
- Complain about the user that they are not using the tool as intended and they probably want to run
dune init project
first if they want a quickstart wizard or carefully place adune-project
file somewhere if they intend to be in a subdirectory. - Create a
dune-project
file in the current directory, and explicitly let the user know about this so that they can delete if if they intended to already be inside a dune project.
Option (2) corresponds exactly to what dune build
was doing on before 3.x. I think it was the wrong UI choice for dune build
, because it is easy to unintentionally run dune build
(or dune clean
or whatever) outside a dune project. It may be the right UI choice for dune init
that users interpret as initializing a project.
This being said: I’m taking your point that dune init
currently has a bad UI and we should discourage users from using it. It’s not just that dune init exe
is weird, even dune init project
does not seem to have the right behavior for quick-starting a Dune project, at least with my local dune 2.9 (this is exactly the issue @yminsky reported at "dune init project" doesn't create a dune project file, creates unnecessary _build file · Issue #5429 · ocaml/dune · GitHub ).