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].
P.S. Currently omod doesn’t work with opam system compilers.
[0]
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.
[2]
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:
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.
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.
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.
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.
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.
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.