> On 6 Dec 2014, at 02:08, Louis Gesbert <[email protected]> wrote:
>
> Hi all,
>
> Following the thread on [email protected] about the needs for teachers
> and the discussion on opam-in-a-box, here is a preliminary specification of
> what I intend to do to improve the situation.
>
> * keep the ad-hoc scripting to a minimum. So that it's easier to maintain,
> contribute, and not get too tied to a given tool (e.g. Vagrant)
Absolutely -- it would be really useful to have a reusable set of scripts that
we could reuse across (e.g.) Docker and Vagrant.
Thomas Gazagnaire suggest pulling out opam-installext from the Docker scripts
into an OPAM package so that we can just install it easily.
> * opam-in-a-box should be just that, a VM or container with a pre-installed
> OPAM. The provisionning command on the VM should be as simple as possible
> (one system-package install, opam init, one opam package install ; possibly
> one more command to serve some web pages)
Agreed.
> * Now the tough part: setting up the account for a nice default user setup,
> with a possible choice of editors. For that I'm starting to work on the 'opam
> package for user setup' (opus ?) ('OCaml TOol Package for User Setup',
> 'octopus' ? :))
I guess this only applies for whole-VM virtualisation like Vagrant. In the
case of Docker packages, we can just skip all this and let the host editor
work. Do we have a page somewhere where we can editor customisation
instructions easily? Right now it's spread across Real World OCaml's
installation instructions, the Merlin website, etc.
>
> ## user-setup
>
> user-setup is a small OCaml program intended to be used as an OPAM package
> with optional dependencies on every tool package it has a module for (e.g.
> merlin, ocp-indent, ocp-index...). Its role is simply to set up the
> configuration of the user to use the installed tools. The idea is to have a
> clean modular interface, with a module for each editor, containing:
>
> - a base config template, to be used if the user has no config yet
> (typically, opam-in-a-box install)
> - a list of chunks that need to be added to given editor files. We'll support
> update of these chunks with correct handling of manual modifications.
>
> then for each tool (within each editor):
> - a similar list of chunks
> - a list of files to link or install
>
> We'll suppose a default configuration for most of this for now, the
> opam-in-a-box setting being the first use-case, and since advanced users
> probably won't use that anyway.
>
> Doing it this way has a bunch of advantages, among them:
> - it should be easy to contribute configurations, and for this, contributions
> are highly needed (I've already put together a good emacs config from the
> various cited sources and my own to start, but am not qualified to do this
> for e.g. vim)
> - it's flexible and allows updates: by using depopts, it will be re-run on
> every tool installation, change or upgrade, only for people to chose to
> install it.
> - it's not normal for an opam package to write outside of ~/.opam, but here
> that'll be well advertised and kept to this one single package, without
> tainting tool packages themselves.
This sounds excellent. What about managing `~/.ocamlinit` as well? That's a
very common missing step among RWO readers.
Anil
_______________________________________________
Platform mailing list
[email protected]
http://lists.ocaml.org/listinfo/platform
