Hi, I am happy to announce the first release of `drom`, version 0.2.0, a tool to create and manage OCaml projects. `drom` is a simple layer on top of `opam` and `dune`, with project and package descriptions written in TOML syntax. It is an attempt at providing a `cargo`-like experience for developers, with builtin support for standard OCaml tools (`opam`, `dune`, `odoc`, etc.) and source managers (Github for now, with Github Actions and Github Pages). There are mainly 2 use-cases of `drom`: * Scafolding tool: `drom` makes it easy to create OCaml projects by generating all the files needed for a standard OCaml project. It creates files for `opam` and `dune`, formatters (`ocp-index` and `ocamlformat`), documentation (`sphinx` and `odoc`), testing directories and Github CI. Once these files have been created, `drom` is not needed anymore and you can keep using your preferred tools. * Management tool: `drom` can also be used to keep managing the project afterwards. It has commands like `drom build` to build the project, automatically installing a local switch with all needed dependencies, `drom doc` to generate the documentation and `drom test` to execute tests. `drom` works as a simple interface over `opam` and `dune` so you almost never need to use them directly. https://ocamlpro.github.io/drom (this site and the documentation was mostly generated by `drom` itself) `drom` is available in the official opam repository. Examples: $ drom new mylib --skeleton library // generate library project // or $ drom new hello // generate program project $ cd hello $ emacs drom.toml // edit the project description $ drom project // update files $ drom build // create local switch and build // or $ drom build --switch 4.10.0 // use global switch and build $ ./hello // run the executable $ drom test // run tests $ drom install // install in opam switch This is an early release to get feedback from users. `drom` has been tested on several of our internal projects, like `opam-bin` and `ez_file`. Since `drom` creates local `opam` switches for every project by default (though it is possible to use global switches too), it is advised to use it with `opam-bin` to speed up switch creation and upgrades. `drom` works by creating projects using "skeletons", i.e. project and package templates. `drom` comes with a few predefined skeletons (`program` or `library`), and allows users to add their own skeletons. We will of course extend the substitution language to help users develop such new skeletons. `drom` is a collaborative work between OCamlPro and Origin Labs. Enjoy ! -- Fabrice LE FESSANT
Hi,
Le 25/11/2020 à 14:05, Fabrice Le Fessant a écrit :
>`drom` is a simple layer on
> top of `opam` and `dune`, with project and package descriptions
> written in TOML syntax. It is an attempt at providing a `cargo`-like
> experience for developers, with builtin support for standard OCaml
> tools (`opam`, `dune`, `odoc`, etc.) and source managers (Github for
> now, with Github Actions and Github Pages).
>
I'm very happy to see work in the OCaml world in that direction. I was currently looking for
duniverse for that kind of need. Do they fullfil different needs or how do they compare?
(As a side question for duniverse people, is it still "Not for public consumption just yet"?)
Best,
--
François
Hi François,
On Wed, Nov 25, 2020 at 2:22 PM François Bobot <francois.bobot@cea.fr> wrote:
> I'm very happy to see work in the OCaml world in that direction. I was currently looking for
> duniverse for that kind of need. Do they fullfil different needs or how do they compare?
My understanding is that `duniverse` tackles the problem of the
"mono-repo", i.e. when you want to manage many different projects as
just one project, using `dune` capacity to build them all at once. I
would say that `drom` tackles an orthogonal problem, which is to
simplify the creation of simple OCaml projects (generating all the
standard files you need, like Makefile, dune-project, dune,
.ocamlformat, .github CI, documentation, license, etc.) and day-to-day
management (changing dependencies, having a copy of headers that you
can insert in new files, etc.). It also provides a single interface
over basic opam/dune commands.
It would probably be possible to use `duninverse` on a set of projects
containing projects generated by `dune`, but I don't know enough about
`duniverse` to be sure.
Of course, `drom` can manage projects composed of multiple libraries
and executables (called `packages` because `drom` generates one `opam`
file for every one of them), but I wouldn't call that a mono-repo,
it's just frequent to have more than one package in a small project.
--
Fabrice