ANOTHER CABAL WRAPPER? HELL NO! Please bear with me. The approach is different from the numerous sandboxing tools we have in that it aims to avoid recompilation by keeping a database of precompiled packages. The database can hold several variants of the same package version compiled against different dependencies. Generally, with hellno you'll get the same result as for blowing away your user package database and doing a nice clean install but without having to recompile everything and with ability to easily revert back and change between projects. For example, suppose you have a project that uses yesod-1.0.0.1 and you want to upgrade to the latest 1.1.0.2. You change your project.cabal, run hellno setup and get: $ hellno setup 61 fixed packages, 98 other packages required. Using 60 precompiled packages, installing 38 ............................................. Which says that you will only compile 38 packages instead of the 98 you would have to wait to finish building if you just had deleted your sandbox/user db. One might argue that with a sandbox you can force reinstalls and get basically the same result, but this would result in lots of broken packages cluttering your sandbox (and after a couple upgrades it will become big and messy so you will probably delete it to start over anyway) and, more importantly, this can't be safely done to a shared sandbox without fearing of something breaking. You can still get away by using per-project sandboxes, though each one can be up to about 100M in size. When you ask hellno to setup the environment for a project it will run cabal --dry-run to determine the required dependencies and then put the symlinks to .conf files in ~/.ghc/i386-linux-7.4.1/package.conf.d/ (or wherever your GHC keeps them) and links to the lib directories in $user_install_prefix/lib. SETTING UP Hellno has a set of packages it calls "fixed", those are usually the core libraries that are installed globally. Any package that wasn't installed by hellno is treated as fixed. That means that you should strip your package database to the bare minimum. Blow away (or backup if you care about it) your user database (rm -f ~/.ghc/i386-linux-7.4.1/package.conf.d/* && rm -rf ~/.cabal/lib/*). Then run ghc-pkg check to ensure that your fixed packages are in consistent state. Now you're ready to run hellno. INTENDED MODE OF OPERATION In a nutshell, use "hellno setup" to switch between projects, "hellno local-install" to install local packages and "hellno depclean" to clean up the hellno package storage. In more detail: Let's say your project doesn't depend on any local packages (local meaning not on Hackage). In your project directory just run $ hellno setup This will bring in all required dependencies, possibly using precompiled packages. If you already ran "hellno setup" for this project (and didn't change the cabal file or run cabal update), this won't have to compile anything. Alternatively, you can pass the list of cabal files to hellno setup like you would to cabal-install and work on several projects without having to switch, but if their dependencies can't coexist, it will fail. Now suppose you have a local lib named foo. Go into its directory and run $ hellno local-install (this will require cabal-install-src being in your PATH). Now you can run hellno setup for projects depending on foo. After you change something in foo you have to run local-install again, as hellno (and cabal) has no way of knowing that foo changed. With time you'll likely decide that your ~/.cabal/hellno/ has grown way too big. To deal with this, you can use "hellno depclean", passing it the projects you're currently working on (unless you want to compile their dependencies again). ON EXECUTABLES Hellno will take care of a package's executables, but only if it also has a library. This is done to simplify the code a bit, under the assumption that an executable-only package cannot be a dependency. Even cabal info won't tell you whether an executable-only package is intalled, since it only tracks libraries. Some of the known issues/limitations: - Version tags not supported. - Error handling is bad. - Since cabal --dry-run tries to use the latest package versions, you get different results from "hellno setup" after running "cabal update", which is actually not that bad a way to update your deps, so maybe this is not an issue after all. TODO: - Rewrite this README so that I stop feeling the urge to put *** LATE NIGHT WRITITNG ALERT *** on top of it.