[This discussion was started on the Haskell mailing list in response to an announcement I made which you can read here http://justhaskell.org/2012/06/13/announce-justhub-sherkin/ At issue is whether the JustHub Haskell distribution for Enterprise Linux and the hub hackage for sandboxing development projects and integrating multiple GHC tool chains is redundant because all of the functionality is covered by the Nix Haskell distribution, allowing as they do multiple Nix Haskell releases to be deployed simultaneously.] (cd = Chris Dornan, al = Andres Löh) cd: > The key feature is the way it integrates the multiple tool chains into cd: > a single virtual tool chain with a sandboxing mechanism provided by cd: > the hub hackage. cd: > I think the Nix distribution might be a natural fit for 'hub' cd: > integration -- I would be happy to work with the Nix people on that cd: > (though it can't be right now). al: If this adds anything in terms of functionality that Nix doesn't already provide, al: then I would be interested to know. From having a quick look at your al: announcements, it's not quite clear though if it does. Hi Adres,
From the original announcement (on the above link):
The JustHub distribution is based on the Hub system for sandbox development that allows each work tree to work in its own sandboxed environment with a specific tool chain and a private user-package database. All of the standard Haskell tools inter-operate cleanly and transparently with the sandboxes and operate in the normal way outside of them. Sandboxed environments (hubs) can be shared between work trees as well as being (re)named, annotated, replicated, swapped, archived, locked and removed. Proper package deletion with the option of garbage collecting orphaned code and documentation is also supported. Where is this functionality provided by Nix? These are the 'key features' that I emphasized in the clarification. I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs all of the ghc drivers into a single bin directory in the user's profile. I am guessing that running `ghc` will generally get you the latest compiler you have installed (7.4.1 in my case); specific releases can be invoked with ghc-7.0.4, etc. This hardly covers all of the above functionality! I think the Nix distribution is excellent and I strongly agree with its functional philosophy -- which I think is the right way to distribute Haskell. Quite related to this (in my mind anyway) are the user-level facilities for managing the package databases that each work tree uses -- the problems that cabal-dev was created to solve. What I have done is to create a system that manages the environment each source work tree uses. If you are in a 2012.2.0.0-based project work tree then the ghc-driver will detect that and invoke the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what you will get when you invoke cabal in such a work tree. However in work trees based on earlier version of the compiler (e.g., GHC-7.2.2), cabal-install-0.10.2 will be used because cabal-install-0.14.0 doesn't interoperate very well with cabal-0.10 and earlier (see https://github.com/haskell/cabal/issues/932). Also in such a work tree you will get all of the tools that were shipped with the GHC-7.2.2 and all through issuing the usual command 'ghc', 'ghci', 'ghc-pkg', etc). Without some system to help the user invoke the right tools in the right context, having to invoke each version of the compiler explicitly can get awkward to use quite quickly. Think about installing a package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal will reach for 7.4.1 unless told otherwise. The only practical way to do this is to build a PATH where the right tools get run on the default commands ('ghc', 'ghc-pkg', etc), or equivalently use intelligent drivers that make sure the right tools get invoked (the method JustHub uses). It is also sometimes helpful to be able to start from the minimal collection of packages that you get with compiler (sans platform packages) and build your collection from there. The JustHub system allows you to do this, even on installations that are working double time as Haskell Platform instantiations. Oftentimes less is more in working out the right package combination! Production Haskell development requires this kind of control over the environment, we have all been doing this for years and it isn't technically difficult. But frankly it sure is tedious, especially when you have worked with something better. And it means that everyone has to hand-build their own developments -- that is wasteful. GHC+cabal do provide an awesome build system but the package management mechanisms aren't as easy to use as they could be. There is no proper mechanism for erasing packages for instance (arguably because it is meaningless -- reinforcing my point) and the mechanisms for managing package databases are inconsistent across the tools (differing between 'cabal' and 'ghc'/ghc-pkg') and not very friendly (requiring the setting up of environment variables and the use of special flags). I have also found it highly useful to be able to name, replicate, archive and share environments between different work trees All of this together (including the missing bits) can make for quite a steep learning curve for those gearing up for writing production Haskell code, and it can get in the way to a surprising degree even for those that have been doing it for a while (or at least that has been my experience). You may dismiss that as pointless or irrelevant but it _is_ a large part of what I am trying get right and it did feature prominently in the announcement. I can see elements of this present in the Nix distribution and cabal-dev and similar tools. But our current standard tools don't make it easy for a developers to unpack a production work tree, ensure the relevant tool chain is installed and just work with it in the precise configuration it needs; each developer has to solve that for themselves. I think the Nix functional approach to distributions is definitely going in the right direction in giving user better control over which packages are installed but, unless I have missed something, I don't think it is so definitive that there isn't room for other developments. Finally a couple of gripes with Nix as a replacement for JustHub. JustHub has a special emphasis on Enterprise Linux (RHEL/CentOS/SL) developers. Because the EL family of O/Ses have such long lifetimes for each O/S release they pose special problems. The GCC tools shipped with RHEL5 are just too long in the tooth for use with recent versions of GHC, which is why JustHub ships with GCC-4.6.1 and binutils-2.21. As we have seen the Nix Linux package doesn't work with CentOS 5 and I have tried to get the Nix distribution loaded onto an up-to-date CentOS 6 system. As far as I could tell that required building the package manager from source but the build failed with an opaque libtool-related message. Because the RPMs are available for Fedora that was much easier to use. Also I could not determine which releases of GHC you are supporting. It looks as the distribution is focused on the Haskell Platform, in which case only those releases of GHC will be available, when they get scheduled for inclusion in the platform. This is a more selective collection than I am aiming to provide with JustHub, but perhaps more importantly, it makes it hard for anyone trying to get hold of an older release of the compiler to find it and load it into Nix. Chris