Add dune-project generation to dune init

[shonfeder]

Closes #4367

This is still in a broken state, but I'll work it in the evenings this week in the hopes of getting it in by next week.

In the meanwhile, there is at lest one point where I could use input on those with dune expertise, so I'm staging the rough WIP for now to solicit advice at key points.

[shonfeder]

Some pointers to help during review.

[ghost]

What is the relation between dune init proj --kind lib and dune init lib?

[shonfeder]

What is the relation between dune init proj --kind lib and dune init lib?

dune init lib and dune init exec and dune init test will "initialize" library, executable, or test components, whereas dune init proj[ect] [--kind=lib/exec] will initialize a project, of the relevant kind.

You might find this pretty confusing and counterintuitive! I do too. I advocated for a different CLI all along the long way of landing init. I made my strongest case against this design in #159 (comment) and in the following exchange, but finally gave in for the sake of being able to move forward with the getting the basic functionality in place.

[shonfeder]

Updated to fix link.

[ghost]

Thanks for the explanation. I didn't realise that dune init could be used to initialise individual components. Who is dune init targeted at BTW?

I'm asking a few questions as I haven't followed closely the development of dune init, but I do plan to review the PR. Generating a dune-project file seems definitely good.

[ghost]

@christinerose could you review the changes to the doc/ folder please?

[shonfeder]

Who is dune init targeted at BTW

The user I've wanted to serve with project initialization has always been non-experts who just want to get a project going quickly. It's meant to be something comparable to cargo new or stack new or npm new etc. (See, e.g., #159 (comment)).

But I think there were conflicting visions and expectations along the way. I think the intended target for the sub-component initialization was experienced users who wanted to automate template generation and maybe eventually for editor integrations? I'm not super sure. Relative to my aims, those were just hoops I needed to jump through in order to land the thing I understand users to be asking for to reduce friction.

If it were up to me, I'd move the project initialization under the new subcommand, and make it work mostly just like tools people are familiar with from other tool chains.

[christinerose]

@christinerose could you review the changes to the doc/ folder please?
With pleasure!

[christinerose]

@jeremiedimino — the spelling changes in 4909 look good to me. Great catches! Those are the only recent changes I see in the Docs folder. Please let me know if I'm missing others.

[shonfeder]

Hi, @christinerose! Thank you for reviewing :)

I am guessing @jeremiedimino is referring to the changes I'm proposing in this PR. This should be just the rst files in this changeset: https://github.com/ocaml/dune/pull/4881/files?file-filters%5B%5D=.rst

[christinerose]

Hi @shonfeder!
Thanks for the clarification! I went over those, and they look really good! I had a few comments. (I'm still new to this process with the comments and doing these edits through Git, so I'm not sure if I'm supposed to "Request Change" below or just "Comment"... so I'll just comment for now) :)

[shonfeder]

Thanks for the fixes and improvements, @christinerose! I think I've addressed all comments targeting at things I introduced here, with the exception of capitalizing cram in the dune file stanza section, which seems like it should stay consistent in the file.

[ghost]

Looks good to me. Just a nitpick regarding the naming of a value. Kudos for the well written documentation!

[shonfeder]

Great. Thanks for the reviews :)

[shonfeder]

Hmm.. There's a CI failure in the formatting-check stage that's only affecting 4.12 on ubuntu:

./dune.exe build @fmt --auto-promote
File "src/dune_engine/package.ml", line 1, characters 0-0:
         git (internal) (exit 1)
(cd _build/default && /usr/bin/git --no-pager diff --no-index --color=always -u src/dune_engine/package.ml src/dune_engine/.formatted/package.ml)
diff --git a/src/dune_engine/package.ml b/src/dune_engine/.formatted/package.ml
index 65ac69a..ea4c0bf 100644
--- a/src/dune_engine/package.ml
+++ b/src/dune_engine/.formatted/package.ml
@@ -444,8 +444,9 @@ module Info = struct
     ; license = Some "LICENSE"
     ; authors = Some [ "Author Name" ]
     ; maintainers = Some [ "Maintainer Name" ]
-    ; documentation = Some "https://url/to/documentation"
-    (* homepage and bug_reports are inferred from the source *)
+    ; documentation =
+        Some "https://url/to/documentation"
+        (* homepage and bug_reports are inferred from the source *)
     ; homepage = None
     ; bug_reports = None
     }
Promoting _build/default/src/dune_engine/.formatted/package.ml to
  src/dune_engine/package.ml.
make: *** [Makefile:92: fmt] Error 1
Error: Process completed with exit code 2.

On the face of it, it seems unrelated to any work on this PR, but I don't want to introduce breakage into the mainline. If anyone has an idea of the cause that would be helpful, otherwise, I'll investigate when I get time.

[ghost]

The failure is only with 4.12 because we only test the formatting (and run tests in general) with 4.12. I did make fmt, committed and pushed.

[shonfeder]

Ah, that makes sense. I wasn't aware. Thank you!

[christinerose]

@christinerose Wasn't that typo addressed here? 256c57f

Perhaps you are referring to a different error? If so, if you can add your change request to the line you have in mind on the latest set of changes, that would help clarify: https://github.com/ocaml/dune/pull/4881/files

Oh yes, it is! Forgive me, as I'm still learning how to navigate all the changes in these different PRs / commits.

[shonfeder]

@christinerose No worries at all: it's a lot to come to grips with. I still sometimes can't figure out where to find the current state of things vs. some past changes :)

Thanks again for the reviews and improvements!