[Nix-dev] How to add tools to a nix-shell environment for haskell development?
Peter Simons
simons at cryp.to
Tue Mar 31 23:04:30 CEST 2015
Hi Michael,
>> why don't you just add those tools into your user's profile?
>
> The short answer is that the examples I gave weren't the best, they
> were just what sorted first in my list of Haskell development
> tools---the ones I believe must be instantiated in that environment
> in order to work correctly are ghc-mod and hoogle, though I may need
> to add an additional wrapper somewhere to get a functioning hoogle.
I don't know much about hoogle, but ghc-mod should work fine regardless
of how it has been installed as long as the environment variables
$NIX_GHC, $NIX_GHCPKG, $NIX_GHC_DOCDIR, and $NIX_GHC_LIBDIR are
configured properly. The nix-shell environment takes care of that, so
arguably ghc-mod doesn't have to part of the nix-shell environment to
function inside of one.
> I am actually uncertain that things will work properly if I just include
> them in my user profile.
As a rule of thumb, executables like cabal-install and ghc-mod work
fine. Packages that ship a Haskell library and need to access that
library at run-time for some reason (i.e. because they want to
re-compile themselves like xmonad or taffybar) must have that library
made known to GHC -- which means including them in the ghcWithPackages
environment.
> * the documentation about how to resolve some of these things is
> scattered around,
> * much of the haskell documentation seems out of date in various ways
> (not addressing haskell-ng, referencing apparently-deprecated things
> like myEnvFun, etc),
> * much of the documentation that's not out of date presumes significant
> familiarity with nix and/or how things used to be done.
All of those points are certainly true. The documentation is going to
improve over time -- that is an ongoing effort --, but it's not exactly
easy to set up a sophisticated development environment right now because
there are so many rough edges.
> * common uses cases in other environments seem unaddressed (presuming
> I'm going to run my editor inside each different nix-shell environment
> is very un-emacs)
I have no trouble with Emacs. The git-version of haskell-mode integrates
perfectly with nix-shell; just run "cabal configure" inside of the
shell, and then any Emacs can use that project, picking up the
configuration from Cabal.
> * you also get to learn not just a new language, but a complex,
> intertwingled system of software management
Yes, the are many moving parts that one needs to figure out to use Nix
and Haskell NG together. There are benefits to it too, though, because
this complicated software management system is extremely powerful once
it's been set up. I just wish the learning curve weren't so steep.
> Looking at this, perhaps the contribution I can attempt is to try and
> turn my experiences into something of a guide for this, though it's
> not something I would trust myself to do solo, because, well, I'm
> still at the madly-flailing stage.
Other people who have the same questions you had will be able to find
answers now via Google, so you're already contributing to the effort
just by actively engaging in discussion and communication. At some
point, most of that mailing list knowledge will have to be polished,
summarized, and added to the Nixpkgs guide. I'll do that soon'ish. It
just so happens that I enjoy hacking code more than writing manuals :-),
but I realize that we're at a stage where documentation is actually more
important than new code.
Best regards,
Peter
More information about the nix-dev
mailing list