I propose to change the CLI as follow:
build command is implicitly assumed if at least one ancestor directory contains a dune, dune-project or dune-workspace fileThe 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.
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:
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)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 execdo 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.
Most helpful comment
I checked selection of
OPAMpackages (1472 packages, Github-only), out of them: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)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
OPAMin total).