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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 18 Jan 2013, at 10:31, Alain Frisch <alain@xxxxxxxxx> 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