Hi all,
I recently created a tool to generate OCaml projects. I constantly have difficulties with dune commands and setting up opam files, etc. Mkocaml generates a dune project with inline tests, opam file, git repository, git ignore, and a Makefile with easy commands. This tool can be of great help to newcomers, allowing them to get up and running faster!
I’m glad to see work and experimentation being done on this problem! We definitely need a smoother story for integrating project configuration and initialization.
Regarding your remark that
I would be very interested in hearing what your primary pain points are around dune commands, since this could help us improve the CLI, and understand where pain points exist.
re: setting up opam files, I’ve been enjoying having my opam files generated by dune, based on the dune-project file. It looks like your current approach here generates the .opam file directly. I’ve thought it might be helpful to have dune init generate the dune-project with a template for the opam configuration. Do you think this might help with some of the woes?
I usually always forgot the commands on generating documentation, and how to run the executable. I go through a series of dune exec to dune exec <name> to dune exec <name>.exe, finally to remember its dune exec ./bin/<name>.exe. Same with dune test, which is really dune runtest.
An issue I have with dune’s documentation is it’s just way too large. To quote Jerry Seinfeld,
Did you see the size of that thing? It’s like the Declaration of Independence. No one is going to read that
I just want to know the bear minimum commands to build/run/publish my project. So writing it all down once in a Makefile with easy names, and generating it for new projects makes it so much simpler for me.
As for generating the opam file with dune. That’s an interesting idea that I forgot dune was capable of. I’ll definitely look into that. Thanks!
The docs are large and complex. But there is a lot to cover as well.
Maybe a bit more verbose output by default. Make it easy to see what is happening.
And then dune/ocaml is just different. I have to write package imports in sexp formatted dune file, for every single folder. It make sense to separate dependencies for complex projects, but it is also very tedious when you start out. You already write the dune-project file with packages. And then once a again in every folder, similar for the all the ppx you use.
Finally try to sit next to an inexperienced developer who needs to setup a dune project. Without helping too much, but just taking notes. Ie a simple hello world webserver.
Also, dune is a fantastic tool and improvement 
!
For what it’s worth, I’d look into providing a set of templates. And keep track of which templates are most popular. Maybe also provide a way for the community to submit new templates, which could be centered around the use of a specific library or framework.
This is a great idea.
@chrisnevers That all makes sense to me. It sounds like some short summary of common commands at the top of the inline help would be useful (cargo does this). Perhaps we could also alias runtest to test.
Templating project setups like you’re doing here is a great improvement. iirc, that was discussed as a planned addition to dune init, but it hasn’t been implemented yet. I think it would be worth opening an issue on the dune repo to discuss incorporating this (and extended work) into the CLI. Would you be interested in opening such a ticket?
So true. Perhaps we could use a slight restructing edit (for instance, the quick start guide doesn’t currently mention the use of init at all).
Your other ideas are great too, I think. I think they’d be nice as feature requests on the issue tracker.
[Edited: posted prematurely]
I wish I had heard of this before
I have working on something like this for Reason
We were working on providing a good starting point in the Reason community as it is very crucial there. We discovered namespace collisions and reported them here with a proposed solution
Currently, we are prototyping the solution in the userland with pesy, hoping to take the feedback upstream.
It’s great to this project nevertheless. I hope to follow it closely and contribute if possible
I think @hcarty had something like that.
He might be interested by your cool thing.
Those are sadly out of date - I should clean them up. Anyone interested is welcome to pull whatever might be useful from them!
Nice idea. I have the same pain point.
Just on the question of how to run the executable, if you set (public_name foo) in the dune file that defines the executable, you should then be able to just say dune exec foo, or more generally if there are command-line args, dune exec -- foo args.
That project hasn’t updated in 4 years
There is also GitHub - tmattio/spin: Reason and OCaml project generator. (last update Jan).
I believe drom is adressing this problem, too, but I’m not using it myself.
Indeed, it’s also the purpose of drom (GitHub - OCamlPro/drom: drom is a wrapper over opam/dune in an attempt to provide a cargo-like user experience. It can be used to create full OCaml projects with sphinx and odoc documentation. It has specific knowledge of Github and will generate files for Github Actions CI and Github pages.), it already includes a nice set of templates for various kinds of OCaml projects (lib, program, ppx, C and Rust bindings).