Loading package installed with opam for use in utop

Learning
1

I’m trying to load package, but without success. I’m following these steps:

opam switch will give me, without any warnings:

→  4.09.0                ocaml-base-compiler.4.09.0           4.09.0

I have ran the command opam install ocurl , so the command opam list | grep ocurl will show, that it’s installed:

ocurl                   0.9.1       Bindings to libcurl

But, when I run utop and try to load the package with utop # #require "ocurl" ;;, there is an error:

No such package: ocurl

When I try to load some other package, which is displayed, when I run opam list like #require "odoc" ;;, then there is no error, but this one doesn’t work.

Do you know why? Thanks

2

Can you try eval $(opam config env) before experiments? Will something change?

3 
#require "curl" ;;

The opam package is called ‘ocurl’, but the ocamlfind name is curl.
ocurl is a very old library. It’s older than the current naming conventions.

4

Thank you. Is it somehow possible to know this in general for a package?

Some command like opam ?show? ocurl, that would tell me what can I then #require

5

Unfortunately not opam knows next to nothing about ocaml.

Given a module M, it is in general difficult to know in which library archive a module is defined, which library archives belong to which ocamlfind packages and which ocamlfind packages are installed by which opam package. Yes it’s an embarassing mess.

If you just want to know which ocamlfind package names you can #require, ocamlfind list can help.

Other than that if you are really stucked peek into the file system rooted at opam var lib.

2 Likes
6

Thanks for further info. I’ll look into those if I encounter this problem with other packages …

7

Somehow I forgot to mention.

You can also use omod which loads modules in the toplevel by their top level name rather than the constellation of other names that exist in the eco-system at the moment.

It’s a data-driven, best effort, approach though and it fails on some modules (generally when these have C externals whose location cannot be inferred by the OCaml objects themselves). But it works sufficently well for me so that I rarely #require these days.

1 Like