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)
* 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)
* 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' ? :))
## 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 seems like the most important part of what we have been discussing on the
Teaching list to me, so I'll focus on it. Hopefully this'll be enough to make
provisionning with Vagrant or Docker (or whatever) trivial. Do we have preset
boxes on Vagrant-cloud yet ?
Now writing the concrete interface.
Cheers,
Louis
_______________________________________________
Platform mailing list
[email protected]
http://lists.ocaml.org/listinfo/platform
