new opam features:
opam install <dir>
After the opam build feature was announced followed a lot of discussions, mainly having to do with its interface, and misleading name. The base features it offered, though, were still widely asked for:
- a way to work directly with the project in the current directory, assuming it contains definitions for one or more packages
- a way to copy the installed files of a package below a specified
- an easier way to get started hacking on a project, even without an initialised opam
opam build, as described in a previous post has been dropped. It will be absent from the next Beta, where the following replaces it.
Handling a local project
Consistently with what was done with local switches, it was decided, where meaningful, to overload the
<packages> arguments of the commands, allowing directory names instead, and meaning "all packages defined there", with some side-effects.
For example, the following command is now allowed, and I believe it will be extra convenient to many:
opam install . --deps-only
What this does is find
<pkgname>.opam) files in the current directory (
.), resolve their installations, and install all required packages. That should be the single step before running the source build by hand.
The following is a little bit more complex:
opam install .
This also retrieves the packages defined at
., pins them to the current source (using version-control if present), and installs them. Note that subsequent runs actually synchronise the pinnings, so that packages removed or renamed in the source tree are tracked properly (i.e. removed ones are unpinned, new ones pinned, the other ones upgraded as necessary).
opam reinstall, and
opam remove have also been updated to handle directories as arguments, and will work on "all packages pinned to that target", i.e. the packages pinned by the previous call to
opam install <dir>. In addition,
opam remove <dir> unpins the packages, consistently reverting the converse
opam show already had a
--file option, but has also been extended in the same way, for consistency and convenience.
This all, of course, works well with a local switch at
./, but the two features can be used completely independently. Note also that the directory name must be made unambiguous with a possible package name, so make sure to use
./foo rather than just
foo for a local project in subdirectory
Specifying a destdir
This relies on installed files tracking, but was actually independent from the other
opam build features. It is now simply a new option to
opam install foo --destdir ~/local/
foo normally (if it isn't installed already) and copy all its installed files, following the same hierarchy, into
opam remove --destdir is also supported, to remove these files.
Automatic initialisation has been dropped for the moment. It was only saving one command (
opam init, that opam will kindly print out for you if you forget it), and had two drawbacks:
- some important details (like shell setup for opam) were skipped
- the initialisation options were much reduced, so you would often have to go back to
opam initanyway. The other possibility being to duplicate
initoptions to all commands, adding lots of noise. Keeping things separate has its merits.
Granted, another command,
opam switch create ., was made implicit. But using a local switch is a user choice, and worse, in contradiction with the previous de facto opam default, so not creating one automatically seems safer: having to specify
opam build in order to get the more simple behaviour was inconvenient and error-prone.
One thing is provided to help with initialisation, though:
opam switch create <dir> has been improved to handle package definitions at
<dir>, and will use them to choose a compatible compiler, as
opam build did. This avoids the frustration of creating a switch, then finding out that the package wasn't compatible with the chosen compiler version, and having to start over with an explicit choice of a different compiler.
If you would really like automatic initialisation, and have a better interface to propose, your feedback is welcome!
More related options
A few other new options have been added to
opam install and related commands, to improve the project-local workflows:
opam install --keep-build-diris now complemented with
--reuse-build-dir, for incremental builds within opam (assuming your build-system supports it correctly). At the moment, you should specify both on every upgrade of the concerned packages, or you could set the
opam install --inplace-buildruns the scripts directly within the source dir instead of a dedicated copy. If multiple packages are pinned to the same directory, this disables parallel builds of these packages.
opam install --working-diruses the working directory state of your project, instead of the state registered in the version control system. Don't worry, opam will warn you if you have uncommitted changes and forgot to specify
Hez Carty (4 May 2017 at 21 h 30 min):
Would a command like “opam init $DIR” and “opam init $DIR –deps-only” work for an auto-intialization interface? Ideally creating the equivalent to a bare .opam/ using $DIR as $OPAMROOT + install a local switch + “opam install .” (with –deps-only if specified) under the newly created switch.
Louis Gesbert (5 May 2017 at 7 h 50 min):
opam init DIRis currently used and means “use DIR as your initial, default package repository”. Overloading
opam initsounds like a good approach though, esp. since the default of the command is already to create an initial switch. But a new flag, e.g.
opam init –here, could be used to mean: do
opam init –bare(it’s idempotent),
opam switch create .and then
opam install ..
The issue that remains is inherent to compound commands: we would have to port e.g. the
opam init, making the interface and doc heavier, and it would only make sense in this specific use-case ; either that or limit the expressivity of the compound command, requiring people to fallback to the individual ones when they need some more specific features.
OCamlPro is a R&D lab founded in 2011, with the mission to help industrial users benefit from state-of-the art programming languages like OCaml and Rust.
We design, create and implement custom ad-hoc software for our clients. We also have a long experience in developing and maintaining open-source tooling for OCaml, such as Opam, TryOCaml, ocp-indent, ocp-index and ocp-browser, and we contribute to the core-development of OCaml, notably with our work on the Flambda optimizer branch.
Another area of expertise is that of Formal Methods, with tools such as our SMT Solver Alt-Ergo (check our Alt-Ergo Users'). We also provide vocational trainings in OCaml and Rust, and we can build courses on formal methods on-demand. Do not hesitate to reach out by email: email@example.com.