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

[Yaron Minsky]

Replying to Louis' response on the teaching list.  If no one objects,
let's keep the conversation here rather than on the teaching list,
since I think we're now into design discussions about user-setup.

On Fri, Jan 23, 2015 at 10:02 PM, Louis Gesbert
<louis.gesbert at ocamlpro.com> wrote:
> user-setup doesn't handle yet the Mac-specific issue of Emacs
> load-paths, so that's probably what is bitting you here; I'll port
> the related code from your .emacs; getting a means to test on these
> ASAP.

Excellent.  Maybe the code I sent in the other email will be useful.
I got it from Jeremie Dimino, so it's better than the dreck I would
put together.

> On hardcoding the paths, I'm still not certain it is the best
> option, but I had a few reasons for doing so (open for discussion,
> obviously, this is still a prototype):
>
> * 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.

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

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

As a general matter, an approach of building infrastructure for "less
sophisticated users" that you wouldn't want to use yourself is a
treacherous one, since it means it's harder to test that it really is
good, since you won't use it yourself!

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

> The alternatives would be (i) using packages supplied within the
> editor's ecosystems, when available (see the detailed discussion at
> [1]), which should clearly handle locations dynamically -- I think
> that best serves advanced users but has a purpose distinct enough to
> justify both approaches ; and (ii) dynamically generating
> configuration at editor run time (like ocp-edit does for emacs: it
> reads its own configuration and outputs elisp code that is evaluated
> at run time)
>
> Note that we still hit a consistency issue with this approach if
> installing user-setup in multiple switches. This also raises the
> question of handling "global" or "multi-switch" packages in OPAM.

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.

> On the feature of dynamically adapting to the latest `opam switch`
> in emacs, it could be achieved by running all external commands
> through `opam config exec -- <command>`. It doesn't extend to
> running different elisp files depending on the switch though, and
> you'd still need to manually update PATH etc. if you're running
> builds within emacs, similar to `eval $(opam config env)`. I do this
> using:
>
>     (defun opam-env ()
>       (interactive nil)
>       (dolist (var (car (read-from-string (shell-command-to-string "opam config env --sexp"))))
>         (setenv (car var) (cadr var))))
>
> opam-user-setup will set this statically, locally on caml/tuareg buffers, which may indeed not be the best idea.
>
> Thanks for the feedback, it'll help make this usable quick
> Louis
>
>> - Yaron Minsky, 23/01/2015 20:48 -
>> Hmm.  I'm still not able to get user-setup to work cleanly on my mac,
>> though depext does install now, and I think correctly determines that
>> there are no packages it needs to install.
>>
>> But here are the messages I get from emacs:
>>
>> Loading paren...done
>> Loading tuareg-site-file...done
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> Making completion list...
>> Starting merlin instance: default (binary=ocamlmerlin).
>> File mode specification error: (file-error "Searching for program" "no
>> such file or directory" "ocamlmerlin")
>>
>> So it can't seem to find merlin.
>>
>> I'm also a little troubled by the hard-coding of paths in the .emacs.
>> Once nice thing about the dot-emacs file I shared with Greg is that it
>> auto-updates where it points on every opam switch, without even
>> needing to restart emacs, I believe.  It would be nice to have this
>> for merlin, though I admit perhaps not with tuareg.
>>
>> I tend to think that until we get this sorted, teachers should use
>> manually put together dot-emacs files like the ones I emailed out.
>>
>> y
>>
>> On Fri, Jan 23, 2015 at 12:39 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
>> > Fixed; there was a minor typo in the `opam` file for the package;
>> > https://github.com/ocaml/opam-repository/pull/3441
>> >
>> > -a
>> >
>> >> On 23 Jan 2015, at 04:33, Yaron Minsky <yminsky at janestreet.com> wrote:
>> >>
>> >> Also, I can't seem to install depext, but the reason doesn't make sense:
>> >>
>> >> Kalessin:~ yminsky2$ opam install depext
>> >> [ERROR] depext is not available because your system doesn't comply
>> >> with opam-version >= "4.02".
>> >> Kalessin:~ yminsky2$ opam --version
>> >> 1.2.0
>> >>
>> >> I'm running the latest opam available from homebrew.
>> >>
>> >> y
>> >>
>> >> On Thu, Jan 22, 2015 at 10:21 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
>> >>> Does depext do anything on a mac?  On redhat? Or is it Debian only?
>> >>>
>> >>> On Jan 22, 2015 10:03 PM, "Louis Gesbert" <louis.gesbert at ocamlpro.com>
>> >>> wrote:
>> >>>>
>> >>>> Just released 0.2 which should fix both issues (opam tuareg mode and
>> >>>> stalling with vim)
>> >>>>
>> >>>>> It would be good to know what we have there now.  It seems like a
>> >>>>> minimum should be:
>> >>>>>
>> >>>>> - tuareg
>> >>>>> - merlin
>> >>>>> - ocp-indent
>> >>>>> - utop
>> >>>>>
>> >>>>> all read to go in emacs.  Getting vim and sublime text support would
>> >>>>> be lovely too, but I think less critical.  What does user-setup
>> >>>>> already support?
>> >>>>
>> >>>> Needs more testing, but we do have those ; vim support also, but it's more
>> >>>> lightly tested.
>> >>>> I didn't figure how to configure Sublime yet.
>> >>>>
>> >>>>> Interesting. Concretely, what would would depext do in this context?
>> >>>>> I did a fresh install of a number of packages on my mac, and I didn't
>> >>>>> need much else, but I may have already had the dependencies in place
>> >>>>> via brew.
>> >>>>
>> >>>> Not sure, but you can use `opam depext -l` to simply show the currently
>> >>>> required external packages.
>> >>>>
>> >>>> The one that bites most often on .deb distributions is the lack of m4,
>> >>>> which is required by ocamlfind. It gets much more complicated as soon as you
>> >>>> want to install e.g. gtk stuff, of course (ocaml-top...).
>> >>>>
>> >>>> Best,
>> >>>> Louis
>> >>
>> >