Re: [Caml-list] [ANN] beta-release of OPAM

[Anil Madhavapeddy <anil@recoil.org>]

On 18 Jan 2013, at 10:31, Alain Frisch <alain@frisch.fr> wrote:

> On 01/17/2013 06:22 PM, Anil Madhavapeddy wrote:
>> I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
>> To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.
> 
> Thanks, this is exactly what I wanted!
> 
> Shouldn't the package be called simply "trunk", without a reference to a version number?

Yeah, but OPAM also has compiler version constraints, so that you can mark a package as requiring {>=4.00} for example.  If the package is just marked trunk, then we need to manually record the version number somewhere.

One option is to have a very high version, so that any packages with a lower bound will continue to work.  The other option (which I chose) is to pick the current working version, since compiler releases only happen a couple of times a year.  We can improve on this...

> I've started to play with opam a little bit, and it's a surprisingly pleasant experience.  Thanks to everyone who contributed to this project!
> 
> Now I want to create my first package.  I've followed the instructions from http://opam.ocamlpro.com/doc/Packaging.html but I don't know where to find opam-mk-repo (I've installed opam from the amd64 linux binary).

(that binary is hopefully just a stopgap until the OPAM binary packages become more widely available)

opam-mk-repo is installed as part of OPAM, so you'll need to install from source.  However, you don't actually need to create a repository unless you want to host a mirror of the tarballs.  Simply try this:

$ mkdir -p my-repo/packages
$ opam remote add localdev my-repo
<create your package inside my-repo/packages/>
$ opam update
<the new packages will be available>
$ opam install <new-package>

The same applies for compilers.

If you specify a git:// or darcs:// URL in the package `url` file, a subsequent `opam update` will refresh the working copy from the remote source.

If you want to work with a local copy of that package, just do `opam pin <package> <dir>`.

If you want the bleeding edge version of a stable package, you can even do `opam pin <package> git://foo/bar`.

Quite the swiss-army knife, but each of those scenarios has come in useful at one point or another, particularly when hacking on Mirage which requires rebuilding lots of forward dependencies if (e.g.) a network driver library is being modified.

-anil