[opam-devel] OPAM Roadmap -- what next ?

Peter Zotov whitequark at whitequark.org
Sun Dec 21 11:39:00 GMT 2014


On 2014-12-21 14:28, Thomas Gazagnaire wrote:
> Hi,
> 
>> - Allow **direct use of more solvers** or solver servers.
> 
> If we go this route I really would like to have a proper `opam solver`
> command (similar to `opam repo` or `opam pin`).
> 
>> - **Support cross-compilation**
>> This is quite an open issue at the moment.
> 
> This needs support on the build system side, so I'm not sure it's a
> high priority for now on (although it would be *very* nice to have at
> one point).
> 
> Something which would be a bit simpler but very still very useful is
> to share things between switches: ie. you want to use install things
> in one switch while using things installed in other ones. Could be
> used to cross-compile (host / target) but also to have a base ocaml
> installation with "layers" of different packages (so need to recompile
> the compiler every-time). Don't have a clear spec of that yet, though.

I completely agree; this is how opam-android essentially works now.
https://github.com/whitequark/opam-android/

It still needs per-package tweaks, so I'm not sure it could be 
automated.

> 
> An other idea related to that: better support for global installation
> where it would be cool to have some (OCaml) packages installed on the
> system which are "external" i.e. not managed by opam (so a fixed
> package version which is not removable). Think mixing both `apt-get
> install` and `opam install foo`. I guess that's also related to the
> 'compiler-as-a-package" stuff ...

That would only work for binaries. I'm not sure how useful would it be.

> Having a way to have
> multiple versions of the same library installed in the same switch
> could be very cool as well, although again it requires support in
> ocamlfind/build systems and it will break quite a few assumptions in
> opam so it won't be very easy to add properly.

This is an extremely bad idea. It has been tried in RubyGems;
the conclusion of both users and maintainers is that it should have
never been added. The main problem is what happens when there are
many disjoint ranges of possible versions for some package:
the behavior gets very unexpected.

-- 
Peter Zotov


More information about the opam-devel mailing list