[opam-devel] opam 1.3 status
louis.gesbert at ocamlpro.com
Sat Dec 19 01:42:35 GMT 2015
> Hi Louis.
> all of this sounds very good. I'd just like to report 3 more features that
> various people have told me about this last months:
> 1/ `opam bundle`: it seems that a few existing projects don't want to tell
> their users to install OCaml and opam. They just want a stand-alone tarball
> that you can decompress and run `configure && make && make install`. There
> are already some patches from @ygrek doing this, that would be very cool to
> integrate the tool upstream
Ah, indeed; these patches should be made easier by the reorganised opam-lib (I
remember there were issues with e.g. OpamArg). I'll see with @ygrek once the
current refactoring is done.
> 2/ local switch/root. few people reported that they would like to use a
> per-project opam root. This could be done easily by making the CLI check
> for a `.opam` directory in parent directories. Or it could work with a
> local config switch file (now that we have only one config file per
> switch), stored in the repository.
Why not, this sounds like a very easy one, at least with the first option --
are there cases where this might get confusing ? The second one would allow
sharing of repositories and `opam update` across "per-project switches", it
boils down to "allow creating a switch with the prefix I supply" -- something
that I intended to add already, the `opam switch` interface needing to be
rewritten anyway, since compilers turned into packages -- and some magic to
automatically choose "current switch" based on PWD.
However, this will only work for opam commands, and you still need to `eval
$(opam config env)`, which really isn't a huge benefit compared to `eval
$(opam config env --root/--switch xxx)` that you need without a specific
I think the best answer to these use-cases is clearly opam-manager , which
was designed for this purpose: it can dynamically choose opam root and switch
based on `.opam-switch` files found in ancestors of PWD, and more importantly,
installs dispatchers for binaries that make them transparent -- without need
for `config env`.
> 3/ local remotes. Currently the remote are per-switch which make them a bit
> annoying when you have a repo with dev packages. Currently it's easier to
> share a list of pins that a remote. So maybe extend `opam pin` to allow to
> take file of packages to pin -- actually it could already work with `opam
> switch import`, so maybe it's just a matter of documentation.
That's on my list too, but I delayed it until I finish refactoring OpamState
-- it's tempting to change everything at once, but often a bad idea. I'm not
sure it will make it for 1.3 though, although, since it will require yet
another format change to ~/.opam, it may be better to have all these changes
at once. In my new version repository state is completely decoupled from
switch state, so the work will mostly be on how to define the repository state
in the ~/.opam layout.
> And last big item, that I haven't seen in your list: windows support: is
> this still on the map?
Yes. I consider it a parallel branch of work, so it may not be synchronised
with 1.3, but effort is being put into this too.
> - Ashish Agarwal -
> Hi. Thanks for this nice summary and ongoing work. Is there any support
> planned for installing binaries? What is needed is a way to specify a
> different tarball depending on the detected architecture. I know some
> people want this for OCaml packages, but actually I'm interested in it for
> our non-OCaml biopam repo .
I did not put this on the list, but have been thinking about it for a while.
Once we have tracking of packages' files, extracting that info to generate
binary packages, or even a full opam repository of binary packages, would be
easy. There are many dark corners though, that may not be a problem for
- optional dependencies: you need to choose whether you want them before
generating the binaries, obviously
- ocaml is not relocatable, which is a big issue, although we have proposed a
compiler patch a while ago and have some hacks available 
- there are actually different approaches available, depending on whether you
just want to cache builds, you want to distribute a bundle, or you want a real
- local setup, external dependencies, etc.
But some stuff on this front is to be expected too!
Hope this clarifies things!
Louis Gesbert, OCamlPro
More information about the opam-devel