Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pckilgore opened this issue Feb 19, 2022 · 11 comments
Open

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

pckilgore opened this issue Feb 19, 2022 · 11 comments

Comments

@pckilgore
Copy link

$ 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
Copy link

imdouyu commented Feb 21, 2022

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

@shonfeder
Copy link
Collaborator

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
Copy link
Collaborator

shonfeder commented Feb 21, 2022

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: #159 (comment))

@shonfeder
Copy link
Collaborator

@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
Copy link
Collaborator

bobot commented Feb 21, 2022

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
Copy link
Member

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
Copy link
Member

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

@bobot
Copy link
Collaborator

bobot commented Mar 9, 2022

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

@bobot bobot reopened this Mar 9, 2022
@bobot
Copy link
Collaborator

bobot commented Mar 9, 2022

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 rgrinberg modified the milestones: 3.0.3, 3.2.0 Apr 22, 2022
@rgrinberg rgrinberg modified the milestones: 3.2.0, 3.3.0 May 4, 2022
@rgrinberg rgrinberg modified the milestones: 3.3.0, 3.4.0 Jun 17, 2022
@emillon emillon removed this from the 3.4.0 milestone Jul 19, 2022
@rgrinberg
Copy link
Member

@gridbugs I believe you fixed this?

@gridbugs
Copy link
Collaborator

No the related bug I fixed was that running dune exec proj created an unintended _build directory in the current directory (#6707)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants