Open dalaing opened 8 years ago
Looks to me like all the ghc-mod
commands need to be invoked from within the nix shell, which is hard since it's a ghc-mod
command that we would use to figure out where shell.nix
is (ghc-mod root
).
EDIT: We would also want ghc-mod
itself to come from that nix shell, in order to be built by the correct GHC, poking another hole...
The ghc-mod you call ghc-mod root
on wouldn't actually need to be built by the project's GHC version FYI.
Sure. But then something still needs to decide to enter the nix shell.
ghc-mod
could just re-exec itself inside the nix-shell, no?
Yes. I'm just wondering how it would go about doing that. It could be done either in elisp or in ghc-mod
itself. It would be weird if users had to have some arbitrary ghc-mod
on their path, as well as a ghc-mod
in their project's Nix shell. I'm currently experimenting with having the elisp find ghc-mod
in the nix shell rather than on the path.
I would really like to have the Haskell bits handle this as then all frontends would work on Nix and not just the Emacs frontend. I agree that it would be awkward to need a random ghc-mod on the PATH but at least that way it would work at all :)
Fair point. Well then luckily this seems to be not so hard. Just relaunch ghc-mod
from within a nix-shell if a shell.nix
is found and nix-shell
is installed.
A stop-gap measure would be to use a proxying script like this one and have ghc-mod
just proxy to a nix-shell running ghc-mod
. The same would be done for cabal
, ghc
, ghc-modi
, etc. I've used this successfully with Atom.
That stop-gap script is working well for me with Emacs.
In some circumstances it might be nice to have it fall back to just running the commands if shell.nix
isn't found, but all of my projects currently have a shell.nix
so that doesn't really effect me at the moment.
@dalaing Great. I had the same thought about a fall-back. Should be easy to add.
Currently ghc-mod is unaware of the package database used in a nix-shell.
There is a PR for this (#760), but a more general approach is needed than just fixing things for Emacs users :)