No subject

	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=20
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=20
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=20
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