The hsenv package
hsenv is a tool (inspired by Python's virtualenv) to create isolated Haskell environments.
It creates a sandboxed environment in a .hsenv/ sub-directory of your project, which, when activated, allows you to use regular Haskell tools (ghc, ghci, ghc-pkg, cabal) to manage your Haskell code and environment. It's possible to create an environment, that uses different GHC version than your currently installed. Very simple emacs integration mode is included.
First, choose a directory where you want to keep your sandboxed Haskell environment, usually a good choice is a directory containing your cabalized project (if you want to work on a few projects (perhaps an app and its dependent library), just choose any of them, it doesn't really matter). Enter that directory:
> cd ~/projects/foo
Next, create your new isolated Haskell environment (this is a one time only (per environment) step):
Now, every time you want to use this environment, you have to activate it:
> source .hsenv/bin/activate
That's it! Now it's possible to use all regular Haskell tools like usual, but it won't affect your global/system's Haskell environment, and also your per-user environment (from ~/.cabal and ~/.ghc) will stay the same. All cabal-installed packages will be private to this environment, and also the external environments (global and user) will not affect it (this environment will only inherit very basic packages, mostly ghc and Cabal and their deps).
When you're done working with this environment, enter command 'deactivate_hsenv', or just close the current shell (with exit).
Named vs Unnamed Environments
By default, hsenv creates an "unnamed" environment, but sometimes for particular use cases you might want to create different environments under the same directory. This is achievable creating a "named" environment. To do that, just pass the flag "--name=<ENVIRONMENT_NAME>" to hsenv:
This will make hsenv to generate a folder of the form ".hsenv_<ENVIRONMENT_NAME>".
The only advanced usage is using different GHC version. This can be useful to test your code against different GHC version (even against nightly builds).
First, download binary distribution of GHC for your platform (e.g. ghc-7.0.4-i386-unknown-linux.tar.bz2), then create a new environment using that GHC
> hsenv --ghc=/path/to/ghc_something.tar.bz2
Then, proceed (with [de]activation) as in basic case.
Fetching and downloading a remote version of GHC
Recent versions of hsenv include the possibility to automatically download and install a GHC version directly from the GHC main repository. To do that, as regards the example above, all you need to do is to pass the desired version of GHC you want to install:
> hsenv --ghc=7.4.1
Or a valid URL pointing to a compressed GHC archive:
> hsenv --ghc=http://www.haskell.org/ghc/dist/7.6.3/ghc-7.6.3-x86_64-apple-darwin.tar.bz2
hsenv has been tested on i386 Linux and FreeBSD systems, but it should work on any Posix platform. External (from tarball) GHC feature requires binary GHC distribution compiled for your platform, that can be extracted with tar and installed with "./configure --prefix=PATH; make install".
For more info please consult "hsenv --help" or the attached README file.
[Skip to ReadMe]
|Versions||0.3, 0.4, 0.5|
|Change log||None available|
|Dependencies||base (>=184.108.40.206 && <4.8), bytestring (>=0.9.1.7 && <0.11), Cabal (>=220.127.116.11 && <1.19), directory (>=18.104.22.168 && <1.3), file-embed (>=0.0.4.1 && <0.1), filepath (>=22.214.171.124 && <1.4), http-streams (>=0.6.0.2 && <=0.7), io-streams (>=126.96.36.199 && <=188.8.131.52), mtl (>=184.108.40.206 && <2.2), process (>=220.127.116.11 && <1.3), safe (==0.3.*), split (>=0.1.4 && <0.3), unix (>=2.0 && <2.8) [details]|
|Copyright||(c) 2011 Bartosz Ćwikłowski|
|Maintainer||Taylor Hedberg <firstname.lastname@example.org>|
|Source repository||head: git clone git://github.com/tmhedberg/hsenv.git|
|Uploaded||Thu Aug 28 02:19:39 UTC 2014 by TaylorHedberg|
|Downloads||3402 total (18 in last 30 days)|
|Status||Docs not available [build log]|
Last success reported on 2015-05-20 [all 6 reports]
For package maintainers and hackage trustees