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

[Louis Gesbert]

> > - 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`).

Why not, there is already something that can be stored in ~/.opam/config but without front-end

> > - **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).

I'm still quite confused on how to get there to be honest. I'd gladly take the time to discuss it with an expert!

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

Two things here:
* just using stuff installed in another switch can be done by (manually, at the moment) tweaking your environment. If that's successful, there is a clear workflow, it doesn't add too much complexity (to the user), and we can build a clear interface for that, then we can go. If the problem is that, at the moment, OPAM restricts the environment of the commands it runs too much, we can see how to get through that to get it tested.
* layering switches: the compilers-as-packages introduces immovable packages, and these can be used for stuff external to the switch as well as the initial installation. So you could well generate a .comp and associated base (immovable) packages that refer to an other existing switch. Remains the problem of upgrade (of the parent switch), but that already needs to be solved to make compilers-as-packages usable with a system compiler.

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

Partly solved by the above ; maintaining a parity between system and OPAM packages sounds very tedious though.

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

It's indeed something that I always keep in mind -- but note that, the sooner we separate the OCaml stuff in a plugin, the sooner this will be enforced.

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

`provides` is well handled by Cudf and thoroughly used in Debian, so I am not too worried on the solver side (more on the handling of our metadata: it'll break a few assumptions).

`features` on the other hand, as currently designed, doesn't actually interact with the solver, alike depopts. They can be used as variables, but only at package installation time and for user information, not for resolution (don't want to go Turing-complete !).

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

The discussion at https://github.com/ocaml/opam/issues/1431 is still open, we'd need to get to some consensus on the specification. Now that the main use-case, opam-doc, has taken another road, what is the priority, and remaining use-cases ?

> > - Find a nicer way to **share dev repos** / undoable "pinning sources"
> 
> What do you mean?

A dev environment is often made of a bunch of pinned packages, which has many advantages over a custom opam repository. But it's much more difficult to share.

See https://github.com/ocaml/opam/issues/1734

> > - **Per-switch remotes**
> 
> yea! dual is global pinned package which is less useful.
>  
> > - **Multi-switch packages**
> 
> What do you mean?

Being able to install a (binary, I assume) package across switches. Mainly useful for editor tools I guess.

See https://github.com/ocaml/opam/issues/1058

> > - Support for (automatic generation of) **binary packages**
> 
> That would be *extremely* useful.

There have been several approaches on this already -- my current idea is a map function on a repository: it would compile every package and generate a corresponding binary archive, at the same time as it generates a corresponding repository (links to the binary archives, no depopts, rewritten deps, etc.)
Of course you'd need to know with what depopts packages should be built, and there are quite a few related issues.

> > - Nicer **ocamlfind interaction**
> 
> What do you mean?

Not sure, but the current duality between OPAM and ocamlfind packages isn't really satisfying.


I didn't mention in this list, obviously, ongoing fixes, optimisation, etc. But there is no end to that :)

Best,
Louis