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

Yaron Minsky yminsky at janestreet.com
Sat Jan 24 11:33:28 GMT 2015


On Sat, Jan 24, 2015 at 1:05 AM, Louis Gesbert
<louis.gesbert at ocamlpro.com> wrote:
> 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.

That sounds good.

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

That seems totally fine.

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

Excellent.  I'll take a look.

y


More information about the Platform mailing list