[ANN] Omod 0.0.1 & 0.0.2


I’d like to announce omod which provides data-driven module toplevel loaders.

Like ocamlfind it allows to load compilation objects and their dependencies in the toplevel. However omod works without additional metadata files and with top level (compilation unit) module names rather than ocamlfind package or archive names.

This means you only need to know the name of the module you want to load rather than having to remember in which ocamlfind package or archive it lives.

It should work well in ocaml, ocamlnat[0] and utop. To get started type:

opam install omod 

and follow the tutorial. More information on how omod came to be is given below [2].

omod is ISC licensed and can be found at http://erratique.ch/software/omod



P.S. Currently omod doesn’t work with opam system compilers.

One issue with ocamlnat is that some libraries lack their cmxs files. E.g. the lack of threads.cmxs prevents the Core module from loading. But other ones like Irmin, Containers or Base do however load in ocamlnat via omod.

This is basically a dependency-less rewrite of odig's toplevel loaders which will be removed from odig. It solves the following problems they had:

  1. Too many dependencies. They brought too many dependencies in
    the toplevel including compiler-libs which are problematic in
    ocamlnat. omod has no dependency, so using it limits toplevel
    scope pollution to the Omod module only which loads fine in ocamlnat.
  2. Resolution for multiple load sequences. odig had no support for
    choosing between multiple load solutions (e.g. for library
    variants). omod has both a variant specification syntax and an
    interactive mode to resolve them.
  3. Slow. They were too slow on large libraries as resolution was done in
    the (bytecode) toplevel itself, omods performance (and API) should be
    improved for scripting however it is reasonably fast for your toplevel
    interactive usage.
  4. Outdated information in long running toplevel sessions. They
    provided no mecanism to update the package information whenever
    the package install base changed.

To solve 1., 3. and 4. the Omod API invokes the omod binary with the load sub-command (whose textual output you can check when you suspect there’s a problem) to find out the load sequences.


That’s a game changer! Thanks a lot.

A small grain of salt, is that now we have a new notion of a package, that doesn’t match with the ocamlfind notion of a package nor with opam notion.

Don’t you think it would be better not to override the package name with yet another meaning, and just use the word directory instead? (or namespace, or path, or whatever).

A workaround could be compiling the cmxs from cmxa in a temporary folder (that is what we’re doing in our own loader). However, this would require a present (and working) compiler, so it most likely create more problems than solve. In fact, those problems should be addressed in the upsteam.

I slightly disagree, it does follow the opam’s notion of installation of a package. This notion agrees with your opam package names as long as they don’t do dirty fancy things like installing in other prefixes.

Unsurprisingly this is also odig's notion of package. Though now that I remember odig did check for the existence of an opam or META file at the toplevel of a libdir’s subdirectory to assert the existence of the package. omod currently has no such test, I may remove the test from odig or add it to omod (the former will be more likely).

Also it should be compatible (or will be made compatible) with a hypothetical notion of ocaml namespace @lpw25 once promised to introduce. Though if I understand correctly the proposal, omod's existence will no longer be needed at that point – a very good outcome.

1 Like

Sorry I overlooked this suggestion. directory would be a bit odd, I do no need some kind of word for this.

This word should not be only for something that organizes names (namespace, path), but that also holds content (see omod pkg --long).

If you have a better word than package why not, but then as I suggeted above this mostly agrees with opam notion of package so introducing a new concept here may be more confusing than enlighting. As such I’m more enclined to leave it so.

1 Like

On 13 June 2018 at 20:07:11, Daniel Bünzli (daniel.buenzli@erratique.ch) wrote:

P.S. Currently omod doesn’t work with opam system compilers.

omod 0.0.2 has been released and solves this problem.

See 0 for all the changes.