[opam-devel] OPAM 1.3 roadmap

Thomas Gazagnaire thomas at gazagnaire.org
Mon Feb 23 11:39:11 GMT 2015


Hi,

An official windows support would be nice indeed.

> * More flexible switch handling (multi-switch packages, per-switch remotes, layered switches for cross-compilation...)

Not very critical but it would be indeed nice to rationalise the design of pin/repo global vs. per switch.

But I think what would be very useful is to think of a (if possible simple) working end-to-end cross-compilation system using opam. Maybe that's just a matter of having opam set the right environment variable to designate the TARGET and HOST switches correctly, and then update opam-repository to configure each package correctly, maybe that's more (involving build system hackeries). But at least I think we should think about it for 1.3.

> * With file tracking, generating a binary repo (with some limitations) could be quite straight-forward.

yay.

Thomas

> Which of these do you think is most important ? Have I forgotten anything ?

yes: we need more colors and more camels. And more animated progress bars too.

Thomas

> 
> Cheers,
> Louis
> 
> 
> [1] http://theupdateframework.com/
> [2] https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins
> [3] https://github.com/ocaml/opam/blob/master/doc/design/provides.md
> From: Louis Gesbert <louis.gesbert at ocamlpro.com>
> To: opam-devel at lists.ocaml.org
> Date: 17 December 2014 10:07:40 GMT
> Subject: [opam-devel] OPAM Roadmap -- what next ?
> 
> 
> Hi all,
>  
> with some lag after the 1.2 release, I'd like to open some space for a collective discussion of the priorities for where the energies should go next. We have mainly 3 directions for improvements: first, portability, with the main goal of a Windows version. Second, agnosticity, with the goal to make OPAM more generic, and try and open it to users outside of the OCaml community (wouldn't OPAM for Haskell be fun ?). Third, there are always lots of features and improvements that have been asked for, and would improve the experience of current users.
>  
> So here is a summary of what I've gathered. Feel free to add your own.
>  
>  
>  
> ## Portability
>  
> - **Rewrite parallel command engine.** / done.
>  
> - **Native system manipulation (cp, rm, curl...).**
> These are mostly done through calls to the shell or external programs. It's
> not very pretty but quite pragmatic actually... until we want to run on
> Windows without Cygwin. Anyway, this wouldn't be the end of portability
> issues.
>  
> - **Windows support.**
> for OPAM itself to begin with. This should be pretty close.
>  
> - **Packages on Windows.**
> Locate common issues and attempt to find generic fixes.
>  
> - Allow **direct use of more solvers** or solver servers.
>  
> - **Support cross-compilation**
> This is quite an open issue at the moment.
>  
> ## Agnosticity
>  
> - **Isolate OCaml-specific stuff.**
> E.g. specific opam-file variables. See ocaml-specific.md
>  
> - **Separate as plugins**
> To open the gate to OPAM without these plugins, or with other ones
>  
> - **Compilers as packages.**
> This should mostly work now, but needs some tests and strengthening. The main
> thing still to do is to handle the system compiler changes properly ; that
> part should be made more generic anyway (see discussion on hooks)
>  
> ## Features
>  
> - A **provides** field. Generally useful, but particulary so with
> compilers-as-packages
>  
> - Releasing the **"features" field** for easier package configuration
>  
> - **Track installed files**
>  
> - **Improve security**: just checking md5s is quite light ; package scripts can
> write anywhere
>  
> - **OS-specific handling of dependencies** (eg dependencies on packages from the
> OS) with plugins (#1519)
>  
> - Specify and implement **hooks**
>  
> - Find a nicer way to **share dev repos** / undoable "pinning sources"
>  
> - **Per-switch remotes**
>  
> - **Multi-switch packages**
>  
> - Support for (automatic generation of) **binary packages**
>  
> - Nicer **ocamlfind interaction**
>  
>  
>  
> Cheers,
> Louis Gesbert
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
> 
> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150223/8d525561/attachment-0001.html>


More information about the opam-devel mailing list