Dune: [RFC] Improving the CLI

Created on 29 Apr 2019  路  10Comments  路  Source: ocaml/dune

I propose to change the CLI as follow:

  • when the first argument starts with a letter, it is always considered as a command name (as now)
  • otherwise, the build command is implicitly assumed if at least one ancestor directory contains a dune, dune-project or dune-workspace file

The idea is to allow the user to type simply dune or dune @all rather than dune build or dune build @all. The first rule prevents ambiguities and the condition on the second rule is to make sure that dune doesn't crawl the whole hard drive when called outside a project.

Most helpful comment

I checked selection of OPAM packages (1472 packages, Github-only), out of them:

  1. 126 use _dune_ only
  2. 643 use _make_ only
  3. 451 use both _make_ and _dune_

Among these 451, default _Makefile_ targets about 445 are various flavors of dune build <args>. Most common are:

  • dune build (236)
  • dune build @install (74)
  • dune build @install --profile=release (16)
  • dune build --profile release (10)
  • various jbuilder build ... (20, half of which have --dev, half - not).

These are rough numbers, since I discarded about 1/3 of repos (there was 2288 repos in OPAM in total).

All 10 comments

Does that imply that dune --help would show me the manpage of the build command instead of the manpage listing the available commands?

That's a good point. I don't think it should, it should be the same as the current dune --help. However, we should extend this man page to document the new behaviour.

I checked selection of OPAM packages (1472 packages, Github-only), out of them:

  1. 126 use _dune_ only
  2. 643 use _make_ only
  3. 451 use both _make_ and _dune_

Among these 451, default _Makefile_ targets about 445 are various flavors of dune build <args>. Most common are:

  • dune build (236)
  • dune build @install (74)
  • dune build @install --profile=release (16)
  • dune build --profile release (10)
  • various jbuilder build ... (20, half of which have --dev, half - not).

These are rough numbers, since I discarded about 1/3 of repos (there was 2288 repos in OPAM in total).

@ksromanov Does dune exec do what you're looking for?

I'm generally in favour of simpler consistency for the CLI, subcommands since higher level tools (e.g. VSCode rules, or Makefiles) invoke dune directly. For them, calling dune build @all isn't a burden at all.

@hcarty

@ksromanov Does dune exec do what you're looking for?

Unfortunately it does not :-(. But yes, you are right - I missed exec. Updating comment above. The idea is to reduce command-line boilerplate.

@ksromanov I feel like we are diverging from the original conversation. Please open a separate ticket to discuss improvements to dune exec.

If the motivation is to type less, wouldn't a shell completion mode be better?

That's a fair point. In particular, I wonder how much we would still want the shorter command line if we add shell completion. Linking the ticket for shell completion: #126

I also think that shell completion would be far more effective and that adding any kind of cleverness is gratuitous. If we make a few straight forward improvements to polling mode, that would cut down on the dune invocations by 90% for me. And as Anil said, proper integration would make this even less relevant.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

erikmd picture erikmd  路  4Comments

shonfeder picture shonfeder  路  6Comments

c-cube picture c-cube  路  7Comments

jeremiedimino picture jeremiedimino  路  5Comments

kyldvs picture kyldvs  路  7Comments