Project initalized with `init exec` does not build (cannot find root)

pckilgore commented 2 years ago

$ dune init exec helloworld
$ dune build

Expected Behavior

A build

Actual Behavior

Error: I cannot find the root of the current workspace/project.
If you would like to create a new dune project, you can type:

    dune init project NAME

Otherwise, please make sure to run dune inside an existing project or
workspace. For more information about how dune identifies the root of the
current workspace/project, please refer to
https://dune.readthedocs.io/en/stable/usage.html#finding-the-root

Reproduction

See commands above

Specifications

Version of dune (output of dune --version): 3.0.2
Version of ocaml (output of ocamlc --version): 4.13.1
Operating system (distribution and version): macos 12.2.1 arm

imdouyu commented 2 years ago

I had this issue, and solved by add file dune-project, which contains (lang dune 3.0)

shonfeder commented 2 years ago

I think this may be a design bug? But I think it also agrees with the documentation and the intended design of init currently. init exec only initiates an executable component, it does not initiate a project. As such, it also doesn’t create a dune-project file.

shonfeder commented 2 years ago

So there’s maybe a documentation/usability issue here. The title of this issue suggests that that the user thought dune init exec Would initiate a project (which it doesn’t).

I’ve never been in favor of the current CLI design around this, and if users keep having this confusion you might consider adopting a more conventional structure of the interface (as I advocated for here, for instance: https://github.com/ocaml/dune/issues/159#issuecomment-477124323)

shonfeder commented 2 years ago

@gasche has some useful suggestions about how to change the behavior around dune init for non-project components: https://discuss.ocaml.org/t/dune-build-error/9387/12

bobot commented 2 years ago

It seems a lot of discussions have already append on this topic, I'm not able to get all the propositions and counter-arguments. But it seems some complications (add vs init) where when a project already existed not when no project existed. Since one can't initiates a component of something that doesn't exists, I think dune init should always create the dune-project file when the directory is not in a dune project. So solution 2) of @gasche. @rgrinberg ?

rgrinberg commented 2 years ago

It seems like we haven't put much thought into dune init post the simplification of root detection. This is only an issue since 3.0 because we now require the root to be explicitly marked somehow. I'm fine with making dune init always create the root at cwd with any template.

rgrinberg commented 2 years ago

Duplicate of #5429. Let's continue the discussion there.

bobot commented 2 years ago

I'm reopening this one because #5429 is not really a duplicate.

bobot commented 2 years ago

After discussion, I think the current UI is not great because dune init doesn't force enough the layout to the users. dune init [lib|exec] create files in the current directory, which is possible only when specifying explicitly the modules with (modules ...) that we don't want to do. We must stick to the simple mantra one directory <-> one library or executable.

Do we agree that at most we want the users to be able to create a repository with those characteristics?

one package
only public binaries and libraries
binaries in <root>/bin/<public_name>/
libraries in <root>/lib/<public_name>/
tests in <root>/tests/

We could support more but at the cost of simplicity in the commands.

The advantage:

we remove the [PATH] argument because we always know where things should go
we can warn user if they create libraries that are not part of the same package
we never need to patch an already existing dune file, since everything is in separate directory

Finally the commands should be more verbose:

dune init proj should advertise the command dune init exec ...anddune init libanddune init test`
all the commands should explain why and for what each files are created
if dune init proj adds a default executable, we should explain how to remove it rm -rf bin

For the problem at hand:

dune init lib PKG.LIB* without a dune-project in parent directory, does first the same than dune init proj PKG

(If possible I would prefer that dune init NAME creates dune-project in the current directory and dune new NAME, if it exists, in directory NAME as cargo, since the UI will already not be backward compatible)

rgrinberg commented 1 year ago

@gridbugs I believe you fixed this?

gridbugs commented 1 year ago

No the related bug I fixed was that running dune exec proj created an unintended _build directory in the current directory (https://github.com/ocaml/dune/pull/6707)

ocaml / dune