[opam-devel] opam 1.3 status

[Louis Gesbert]

> 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 
feature.

I think the best answer to these use-cases is clearly opam-manager [1], 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`.

[1]: https://github.com/OCamlPro/opam-manager

> 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 [1].

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 
biocaml:
- 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 [2]
- 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 
binary repository
- local setup, external dependencies, etc.

But some stuff on this front is to be expected too!

[2] https://github.com/OCamlPro/ocp-reloc


Hope this clarifies things!

Best,
Louis Gesbert, OCamlPro