[ocaml-platform] opam-in-a-box

[Louis Gesbert]

You're making important points; this is an area where pragmatism is way above consistency or simplicity of design, just because the one direction it'll have to scale is users.

> > * this is not focused on advanced users with multiple switches,
> >   etc. and it makes the configuration simpler to understand and
> >   edit.
> 
> Fair, although it would be a lot better if this created dot files that
> were suitable for people who wanted to extend to more advanced use
> later.  Setting up emacs files and the like is quite painful, even for
> sophisticated users, and I think a lot of them would appreciate the
> help.

Agreed: best if it can be scaled to the needs of more advanced users without having to restart configuring from scratch, let's not add more steps than needed.

> > * user-setup configures editors depending on what is installed in
> >   the current switch ; it may not make sense in other switches.
> 
> I'm tempted to think that this is a mistake, as I said in my previous
> email.  I think we'd probably get a more readable and robust set of
> emacs configs if they just auto-detected what was there, and
> conditionally enabled those bits of editor automation.

Hmm, I was afraid of writing something that could get inconsistent, but indeed, if possible, there is no good reason not to add the detection code in the editor itself. Tool-configuration snippets may still be useful in some cases (less versatile editors), but it's best to put as much as possible in the base snippet for the editor.

> > * some tools are generally useful (tuareg, ocp-indent) and
> >   installing them in one switch should be enough. There is a clear
> >   distinction though for compiler-version dependent tools (merlin,
> >   ocp-index).
> 
> Yeah, that's a good point.  I think I'd personally prefer to just
> install tuareg and ocp-indent and the like in all my switches, and
> have merlin and ocp-index work properly as I switch.https://github.com/AltGr/opam-user-setup

Nothing is actually preventing us from being static for the first class of tools (tuareg, indent), and dynamic for the second class (compiler-specific ones), except maybe complexity and readability. I'd like to have similar (dynamic) code for all, but then set a static path for first-class tools so that it'll still work if you don't install them everywhere.

> > * this approach is guaranteed to be available for all editors.
> 
> Perhaps we should do something more custom for individual editors.  We
> could just have different packages for different editors, vim-support,
> sublime-text-support, emacs-support, etc, which had some useful
> dot-files and a setup script for them.  I'm not sure a one-size-fits-all
> -editors approach is going to really be possible here.

I'd still like to try: there is an (editor x tool) matrix that can quickly gain in size, and gathering everything at a single place will really help maintaining various combinations, or at least knowing were to search. If it explodes in size, we can still start referring to other packages.

> If we get user-setup to install a robust set of emacs (or vim, or
> sublime text...) macros, there isn't really a switch problem.  After
> all, my current emacs configs work fine when I flip between different
> switches.  If all user-setup is a set of configs to install such
> robust scripts, we're in a pretty good place.
> 
> In other words, maybe we should focus on building highly robust
> scripts first, and then just have an easy delivery mechanism for those
> scripts in opam.

That's indeed my goal, maybe I over-engineered the tool. But I am also concerned with the convergence for such scripts: everyone typically tends to have his or her own tailored version of the editor configuration, and is generally reluctant to swap it for one in n integrated solutions, so it's really important to manage and focus the effort somewhere for establishing and testing these files.

I just updated the README at https://github.com/AltGr/opam-user-setup to reflect these thoughts in one place (it's by no means the end of discussion)

Best,
Louis