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
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
