Update vendored cmdliner to 2.0

[shonfeder]

Given the release of Cmdliner 2.0, we should plan to update our own vendored variant.

This should let us solve #126

The need for this work was flagged by @ElectreAAS .

[shonfeder]

@ElectreAAS has not had time to work on this, afaik, but @Sudha247 is ready, so I am swapping out the assignee to reflect that.

[anmonteiro]

Note for whoever works on this: we'll likely want to revert the behavior in dbuenzli/cmdliner#200 in our vendored version, since that would be a huge breaking change.

[Sudha247]

When I looked into this issue, I thought it would be a fairly straightforward update: pull in the upstream changes and rebase the Dune parts that use cmdliner on top of them. For clarity, what I intended to do was:

• Pull changes to cmdliner in dune's fork, which is currently at cmdliner 1.2.0.
• Update the vendored version in the Dune codebase via [the script in Dune].(https://github.com/ocaml/dune/blob/main/vendor/update-cmdliner.sh).
• The previous step might most likely prompt some changes to be made in Dune itself.

I haven't been following cmdliner's developments - I found - and as @anmonteiro remarked above there are some breaking changes in cmdliner 2.0.0 that makes the transition more challenging. opam has tried to upgrade to cmdliner 2.0.0 and decided to keep at 1.3.0 for now: ocaml/opam#6435, ocaml/opam#6755, mainly because of the breaking change around option name prefixes. I don't immediately see a nice way to revert just this behaviour, and this maybe needs more consideration from Dune's end. I'm deferring this for now, for after the MSP milestone, but I'm keen to hear thoughts from people if any

[ElectreAAS]

I am of the opinion that the entire reason for moving to cmdliner 2.0 was that breaking change you mentionned: not being able to type dune bui instead of build. I think while it is technically breaking, it is a positive change.
I don't think (but I may very well be wrong in this) that dune is a different position to opam: we don't have a lot of long command names that were previously shortened by cmdliner.
Teaching users about the correct usage is imo a better idea.

[shonfeder]

Unfortunately widely documented/recommended ways for setting up projects does depend on the shortening for dune init proj. E.g.,

• https://ocaml.org/docs/your-first-program#compiling-ocaml-programs
• https://dev.realworldocaml.org/platform.html#the-ocaml-platform

Teaching users about the correct usage is imo a better idea.

The issue here is that we are changing the definition of "correct". We can do that, of course, but will be disruptive unless we are deliberate.

One easy fix may be to introduce command aliases for cases like this, so that, e.g., dune init proj becomes a shorthand for dune init project.

[dbuenzli]

While this may disappoint @ElectreAAS (but I share her sentiment :-) it should be safe, unless there is a bug in cmdliner, to simply upgrade to cmdliner 2.0.0 and apply this patch behind:

diff --git a/src/cmdliner_trie.ml b/src/cmdliner_trie.ml
index 4b520ff..965dfab 100644
--- a/src/cmdliner_trie.ml
+++ b/src/cmdliner_trie.ml
@@ -83,9 +83,4 @@ let of_list l =
   let add t (s, v) = match add t s v with `New t -> t | `Replaced (_, t) -> t in
   List.fold_left add empty l
 
-let legacy_prefixes ~env = match env "CMDLINER_LEGACY_PREFIXES" with
-| None -> false
-| Some s ->
-    match String.lowercase_ascii s with
-    | "true" | "yes" | "y" | "1" -> true
-    | _ -> false
+let legacy_prefixes ~env = true

This would allow dune to benefit from the cmdliner 2.0.0 many improvements while unconditionally retaining the pre 2.0.0 prefix specification behaviour. Note however that this will also change some cli parsing error message, including use of ANSI styling according to this behaviour.