[Nix-dev] development environments
Marc Weber
marco-oweber at gmx.de
Sun Feb 24 11:52:07 CET 2013
The overlay dumps the hackage package information into a .nix file.
Then a nix code tries to determine dependencies based on (eventually
patched) cabal file contents creating the .nix derivations on the fly
depending on what you asked for.
Because brute force is used only a limited set of haskell package
versions is used when resolving dependencies.
Advantage: Very often it just works.
Disadvantage: If it does not it still requires some debugging and patching.
Depeding on cadal flags the right dependencies are chosen automatically.
Eg if you have
foo-1.0
dependencies:
if flag-A
LIB_IF
else
LIB_ELSE
Then either LIB_IF or LIB_ELSE will be passed as build input depending
on flag configuration.
Darcs on its own has more than 8 flags, thus there are 2**8 different
ways to configure it (not counting slightly different versions in the
dependencies). Thus in theory its strong enough to find a working
configuration, but in the real world there are too many ways, which is
why its me setting sane defaults.
Because the whole dependency chain is calculated on the fly its possible
to inject your own dev version of a packages:
Eg make darcs depend on bytestring-my-9999 version.
Because dependencies are calculated on the fly, and the end result is
only a script you install into a directory specific profile you can have
multiple profiles.
source ./ghc-6.0-setup # then compile with ghc-6.0
2nd shell:
source ./ghc-7.x-setup # then compile with ghc-7.x
Thus testing multiple configurations at the same time using different
shells is made easy.
Because I don't do much Haskell at the moment the hackage dump I created
is a couple of month old. If you're interested I can show you how to
update it yourself.
Marc Weber
More information about the nix-dev
mailing list