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

[Thomas Gazagnaire]

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.

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 ...
 
> ## Agnosticity

This bit will not really benefits OCaml users, so it's not a high-priority for now on. But it is good designs principles to keep in mind when adding new features (as Daniel mentioned). It is also interesting if we want more people using opam outside of the OCaml world, but that's an indirect/longer-term target I'd say.

> ## Features
>  
> - A **provides** field. Generally useful, but particulary so with
> compilers-as-packages
>  
> - Releasing the **"features" field** for easier package configuration

We need new features to help managing the grow of the number of packages. I think both of these features could help, but as they are interacting with the solver we need to check that we are not doing things too crazy with the solver experts. 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.

> - Specify and implement **hooks**

Would be nice to have (with clear indications to the users than something fancy is happening) but that's not a blocker for opam-doc. 
>  
> - Find a nicer way to **share dev repos** / undoable "pinning sources"

What do you mean?
 
> - **Per-switch remotes**

yea! dual is global pinned package which is less useful.
 
> - **Multi-switch packages**

What do you mean?

> - Support for (automatic generation of) **binary packages**

That would be *extremely* useful.

> - Nicer **ocamlfind interaction**

What do you mean?

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20141221/e217d5f6/attachment.html>