elisp: Installation Methods

[DanielG]

I'd like to change the preferred installation method for ghc-mod's elisp/ code. Having to keep the stuff from MELPA and the executables installed through cabal up to date and in sync is annoying so I'd like to make this more streamlined.

In theory we could simply distribute the elisp/ bits through cabal and instruct the user to add elisp/ to their load-path. However since the path contains ghc's and ghc-mod's version numbers by default the user would have to update this every time they update ghc-mod.

One way to get around this would be to have the ghc-mod MELPA package simply discover the path to the elisp/ directory installed by cabal-install, add this to load-path.

There are probably some problems with this approach most notably ghc-mod-autoloads.el would have to be generated before creating the cabal source distribution so I'm open to suggestions.

The good thing about this is that we would probably not have to update the MELPA package very often and users could upgrade by simply installing a more recent version of ghc-mod through cabal.

[sebeaumont]

@DanielG Maybe adding a command to ghc-mod e.g. 'locate' would enable this to find the right root of the ghc-mod installation (I tend to build everything in sandboxes these days and ln -s to the executables which makes it even trickier to resolve to the right version). I think this is what the Agda folks do for their emacs integration.

[DanielG]

I don't know why I didn't think of that, though one problem is that before IIRC ghc-7.6 you can't get the full path to the current executable so there we'd have to guess :/

[sebeaumont]

Well Agda has been around for a while -- let me have a look at their implementation... looks like they use a cabal generated module called Paths_Agda to do the magic... I'll see if I can figure it out...

[DanielG]

Yeah that's cabal magic, but I'm afraid that might not work in all situations especially with distribution packages. For example debian usually installs stuff into a temporary directory and then packs it up into a .deb, so the path we get from cabal might be the path to the tmpdir on the builder's machine instead of where it actually gets installed to..

[sebeaumont]

Agreed that's a hack not a solution. Hmm back to the drawing board...

[DanielG]

Then again for the distribution case we could just search standard paths. The ghc-mod debian package should install the autoloads in the right place anyways.

[sebeaumont]

Maybe executable-path might do it. It seems there is no platform independent (or reliable) way to get an executable to tell us where it is and the argv[0] environment is a parameter to exec and can be arbitrary. I suppose setting up a bunch of standard search paths + executable-path might be the best that can be done.

[sebeaumont]

doesn't work with symbolic links... :(

[DanielG]

Does it just crash or return the wrong thing or what?

[sebeaumont]

Just returns the path of the link and not the real path... so there's a bit more to do for my use case -- this wouldn't work for something like homebrew installed binaries on os x, for example, which are always links to where the actual versions are installed. I use the same kind of scheme for all my installed Haskell binaries.
I'll see if the link can be resolved portably. I think it would depend on the use case as to the correct semantics of how this should be resolved. Who would have though such a thing to be so subtle...

[DanielG]

Canonicalizing symlinks while fiddly is pretty easy so that shouldn't be a problem.

[sebeaumont]

Yes that works ok. On another tack shouldn't cabal install put the lisp files into a standard place that we could just add to our emacs load path as you originally suggested? Since these are platform independent why does cabal bury the datadir stuff in architecture/version specific dirs? In fact as it stands, resolving the executable path doesn't solve this as cabal puts its binaries in a standard place, either .cabal-sandbox/bin or ~/.cabal/bin it should do the same for datadir stuff - e.g. .cabal-sandbox/share/elisp ...

[etrepum]

Keeping something on MELPA would be convenient for installation, but it should be bootstrap code that doesn't need to be updated. Minimally it could start up ghc-modi which would have a command to emit the location of the elisp files which it would then add to the load path and continue the bootstrapping process. Sounds like having ghc-modi find those files reliably might be tricky, but not impossible.

[DanielG]

Well Cabal allows us to compile in the installation paths using the Paths_ghc_mod stuff so getting the location of the elisp stuff installed alongside the executables is trivial. Though it does make installation a little less flexible as you now can't simply copy around the executables etc. but rather have to tell cabal where you want stuff to be installed. However cabal-helper already uses a this stuff so it doesn't matter anyways.

[etrepum]

I just prototyped something that seems to work in #492

[DanielG]

Well that was quick :)