Held back by inability to access libraries

I’m sure this question has been asked and answered many times, but I am unable to install and then access many of the great libraries created by the Ocaml community.

Take Base as an example. I run:

opam install Base

It shows up when I run:
opam list

but if I use the REPL to open it, or try to include it in a script, I get the dreaded ‘Unbound module’ error. I have seen various answers online referring to an ‘.ocamlinit’ file, but I have no idea where it is located or what to do with it.

I am a F# refugee, so some of the extra work needed to get Ocaml working correctly is foreign to me.

Any (simple) instructions gratefully received.

To use base in the ocaml toplevel after installing it, you need to type:

#use "topfind";;
#require "base";;

Cheers,
Nicolas

1 Like

Thanks, that works in the REPL. How would I write that in a file to be compiled by ‘ocamlopt’? (It doesn’t like the #use directive).

If compiling by hand (ie without using Dune), you can do:

$ ocamlfind ocamlopt -package base -linkpkg foo.ml

Cheers,
Nicolas

2 Likes

You should probably learn about dune in that case.

2 Likes

Thanks. My main reason for using Ocaml is as a back-end to Python Qt, which is graphically great, but Python itself is a ludicrously fallible language. So my compile commands look like:

ocamlopt -shared word.ml model.ml -o model.cmxs

Could I do something similar in the compile to include the packages?

There is a package called ‘ocaml-in-python’ which enables Python to use these libraries, which is the perfect combination for me.

Yes:

ocamlfind ocamlopt -package base -shared word.ml model.ml -o model.cmxs

There is one subtetly: if base will be linked to the “main” program (the one loading the plugin model.cmxs), then the above command is OK. Otherwise, if base needs to be linked into the plugin itself, then you need to add -linkpkg to the above command line.

Cheers,
Nicolas

1 Like

Many thanks for your prompt and informative replies.

I’ve been trying to solve this for awhile.

I’ve been there, OCaml toolchains do have more moving parts for dubious reasons. Assuming you’re used to .NET F# (rather than Fable), here’s how I mentally map F# tooling to OCaml:

  • Instead of NuGet and MSbuild, OCaml has opam and dune, except:
    • Packages are installed per opam “switch” instead of restored per script/project.
    • dune can’t just install the packages for the libraries you reference, you first need to install your dependencies separately with opam.
  • On the top-level (interactive/scripts), instead of referencing packages with #r "nuget:_", OCaml has #require "_", but to use #require on a bare top-level you first need to #use "topfind";;. Other tools can automate these directives.
  • If you use dune:
    • Instead of project files (.fsproj), there’re dune files with one or more executable/library stanzas.
    • dune files must belong to a workspace, usually a single dune-project file on the root of the repository.
    • Instead of PackageReference/ProjectReference, dune has fields like libraries, but again the actual packages are managed separately with opam.
    • However, dune can help generate .opam files to write your own packages and list your dependencies.
  • If you run the compiler directly instead, drive it with ocamlfind so you can resolve package references with -package <name>.
5 Likes

I’ve been working on a crash course style tutorial to introduce an OCaml beginner to the the SQL library called caqti (with the help of its author)

I had someone like you in mind when I wrote it, so you may find it useful.

If talking to a database is something you’d need, then the tutorial should be that much more interesting.

You can find the work in progress here:

The first 2 projects (hello-world and hello-tests) should give you just enough hints to get going with OCaml.

Don’t hesitate to give me feedback if something didn’t quite work out

4 Likes