Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Does Hub know about system-level libraries that Haskell packages need to build, like Gtk, ADNS, Avahi, etc.? As is the case for cabal-install, ensuring the right system libraries are installed is outside its scope. Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
[Sorry for the delay -- I missed this reply until prompted.] Very nice, this looks quite straightforward. I wonder about two things: - Is it possible to pass configure-time flags to those libraries? For example, I would like to build haskeline with -fterminfo. Can Hub do this? - How do you handle packages that depend on system libraries? hsdns, for example, requires the adns library to build. Does Hub know about this? Well observed! There is currently no provision for getting special arguments passed to cabal install when rebuilding the packages -- a weakness that should be addressed. Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, I'm also wondering about this issue: - How do you handle packages that depend on system libraries? hsdns, for example, requires the adns library to build. Does Hub know about this? Does Hub know about system-level libraries that Haskell packages need to build, like Gtk, ADNS, Avahi, etc.? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, hub save project project.har I am curious to see what this file looks like. Could you please post a short example of one? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Peter, hub save project project.har I am curious to see what this file looks like. Could you please post a short example of one? There is a worked out example at the bottom of the overview up on the web site: http://justhub.org/overview The configurations are quite simple, just listing the global package and the list of packages in the user database. When I provide command sets for refining the versions of the tools used with each hub (esp. cabal-install, only possible by hacking the configuration file at the moment) I will add this information to the hub configuration archives. Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, There is a worked out example at the bottom of the overview up on the web site: http://justhub.org/overview thank you for the pointer, I think I found it: ^=7.4.1 List-0.4.2 fgl-5.4.2.4 hexpat-0.20.1 mtl-2.1.1 regex-base-0.93.2 regex-compat-0.95.1 regex-posix-0.95.2 text-0.11.2.1 transformers-0.3.0.0 utf8-string-0.3.7 Very nice, this looks quite straightforward. I wonder about two things: - Is it possible to pass configure-time flags to those libraries? For example, I would like to build haskeline with -fterminfo. Can Hub do this? - How do you handle packages that depend on system libraries? hsdns, for example, requires the adns library to build. Does Hub know about this? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris,
How much time, approximately, did you spend working with Nix?
1 hour? 10 hours? 10 days? 10 months?
You know that it is not 10 months.
actually, no. I don't know that, which is why I asked. I find it hard to
get an answer from you, though. It seems strange that you keep such
trivial information to yourself like some super personal secret. The
point of this discussion is to compare the respective properties of Nix
and Hub. In that context, it seems natural that I might be curious how
much actual working experience you have with Nix.
JustHub [and Nix] have some similarities -- mostly around the idea of
allowing multiple tool chains to co-exist; the way they go about it
is very different.
I'm not sure what differences you are referring to. Could you please be
a little bit more specific? How exactly do Nix and Hub differ in the way
they install multiple tool-chains?
I also know that I have been adding things that a generic package
manager is most unlikely to be covering [...].
What you mean is: you really don't know, but you are speculating.
To take just one example, I provide a mechanism that allows
developers to archive the configuration of their Haskell development
environment and check it into a source management system. The
developer can check it out on a another system and if the build
process invokes the recovery mechanism it will automatically rebuild
the environment on the first run [...].
Yes, is Nix we solve that problem as follows. Configurations are lazily
evaluated functions. The function that builds Hub, for example, looks
like this:
| { cabal, fgl, filepath, hexpat, regexCompat, utf8String }:
|
| cabal.mkDerivation (self: {
| pname = hub;
| version = 1.1.0;
| sha256 = 0vwn1v32l1pm38qqms9ydjl650ryic37xbl35md7k6v8vim2q8k3;
| isLibrary = false;
| isExecutable = true;
| buildDepends = [ fgl filepath hexpat regexCompat utf8String ];
| meta = {
| homepage = https://justhub.org;;
| description = For multiplexing GHC installations and providing
development sandboxes;
| license = self.stdenv.lib.licenses.bsd3;
| platforms = self.ghc.meta.platforms;
| };
| })
When Nix runs that build, it's executed in a temporary environment that
contains exactly those package that have been declared as build inputs,
but nothing else. Since all built-time dependencies of this package are
arguments of the function, it's possible to instantiate that build with
any version of GHC, Cabal, fgl, filepath, etc. If I pass GHC 6.12.3, Hub
will be built with GHC 6.12.3. If I pass GHC 7.4.2, Hub will be built
with GHC 7.4.2 instead.
Now, in my home directory there is a file ~/.nixpkgs/config.nix that
works like the 'main' function in a Haskell program insofar as that it
ties all those individual functions together into an user configuration:
| let
| haskellEnv = pkgs: pkgs.ghcWithPackages (self: with pkgs; [
| # Haskell Platform
| haskellPlatform
| # other packages
| cmdlib dimensional funcmp hackageDb hledger hledgerLib hlint hoogle
| HStringTemplate monadPar pandoc smallcheck tar uulib permutation
| criterion graphviz async
| ]);
| in
| {
| packageOverrides = pkgs:
| {
| ghc704Env = haskellEnv pkgs.haskellPackages_ghc704;
| ghc741Env = haskellEnv pkgs.haskellPackages_ghc741;
| ghc742Env = haskellEnv pkgs.haskellPackages_ghc742;
| };
| }
I can copy that file to every other machine, regardless of whether it's
a Linux host, a Mac, or a BSD Unix, and run
nix-env -iA ghc704Env
to have Nix build my GHC 7.0.4 development environment with exactly
those extra libraries that I configured.
How would I do something like that in Hub?
Maybe Nix provides such a mechanism -- I don't know.
It does. :-)
Take care,
Peter
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
How would I do something like that [save and restore a Hakell project configuration] in Hub? Once I have an environment I am happy with, I save its configuration (here the hub is named 'project'): hub save project project.har I would check this file into the source repository and at the start of the build process (it could be in a script or makefile) I would load it thus: hub load project project.har While the build environment is stable this will just check that the environment matches the configuration and immediately continue with the normal build process. But when I check out and build the source tree on another system it will locate the tools specified in the configuration file and rebuild the user package database, complaining if it can't locate the right tools. There are more examples at http://justhub.org/overview Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris. [Sorry if I'm slow responding, but I'm at a summer school right now and have relatively little time to follow my email.] 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.] Let me clarify this in advance: I'm *not* questioning the usefulness of JustHub at all! It's great that you provide it. I was asking whether integrating JustHub *into* Nix and/or NixOS would make sense and would provide any benefit on top of the features already provided by these systems. As I indicated, I'm not yet convinced of that. I asked the question in order to learn more about JustHub. I do completely understand that Nix is not for everyone and that JustHub may have less dependencies that make it a very attractive choice for a wide range of applications. All of the standard Haskell tools inter-operate cleanly and transparently with the sandboxes and operate in the normal way outside of them. I guess this may be the main point. You're saying you can use the standard tools to work with hubs and don't need to do anything special, whereas in Nix(OS) you admittedly only get the full benefit of the system if you're installing packages via Nix rather than via Cabal. As Peter has pointed out, you're usually working in Nix(OS) with several profiles. Each of these profiles can contain an arbitrary set of packages (not limited to Haskell or GHC). It's possible to switch between profiles easily. It's possible to use different profiles for development on different projects. Different profiles can contain different versions of GHC as well as different sets or variants of packages. 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. I'm not completely sure what each of these mean. Package removal is certainly supported in Nix(OS), but again, admittedly, not via the standard tools. You have to invoke nix-specific commands in order to perform garbage collection. 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. Installing the latest version into the main user profile is merely the default functionality. There's absolutely no problem selecting older versions or installing into separate profiles. If you look at the files actually installed, you'll find that all files in a profile are just links, and that each Haskell package in fact lives in isolation in its own directory in the Nix store. This hardly covers all of the above functionality! It might not. We're having this discussion in order to find out, I think :) 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. You still have to say at some initial point what version you want to use, I hope? Otherwise, I can't see how it could be detected. 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). Independent of concrete bugs, who's making these decisions? Can I use cabal-install-0.14.0 on projects working with older platforms if I want to? 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. This is not required in Nix(OS). You switch the profile and then get the versions you have in your profile. The profile is not tied to working dirs, you have to manually switch. I think both approaches have their disadvantages in practice (i.e., either the user shell or the working dir are
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Andres, Thanks for your detailed reply -- it is much appreciated. Independent of concrete bugs, who's making these decisions? Can I use cabal-install-0.14.0 on projects working with older platforms if I want to? Out of the box you get a set of tools that avoids known problems and complies with the particular platform. It is easy to override this in the configuration file. I expect to add commands to carry out that reconfiguration soon. Not a problem in Nix(OS) either. Indeed, for each compiler version I have standard plain and platform profiles installed on my machine, Excellent! You still have to say at some initial point what version you want to use, I hope? Otherwise, I can't see how it could be detected. Indeed. It can be done statically (by configuring the directory) or dynamically (by setting an environment variable). I think I am getting a feel for how Nix works. As I understand it Nix provides the user with fine control of the combination of packages that can be installed in a profile. A user can maintain many profiles and switch between them. (As I have been saying) I like it. Most of the issues I have been addressing in the hub system are concerned with managing the Haskell user package database. Each project needs to know where to find the tools and where to find the global package database but they are generally static and come pre-packaged in the configuration file. The real action in the Hub system lies in managing the user package database. As I see it the developer's project configuration belongs in the source code repository. Once the developer has checked out the work tree the tools should take care of the rest. (And the tools behave as normal in the absence of such configuration.) Everything I have been trying to do has been geared towards this and helping the developer to manage the development environment. Cheers, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, Where is this functionality provided by Nix? simply run these commands # Haskell Platform 2009.2.0.2 nix-env -p ~/ghc-6.10.4 -iA haskellPackages_ghc6104.haskellPlatform # Haskell Platform 2010.2.0.0 nix-env -p ~/ghc-6.12.3 -iA haskellPackages_ghc6123.haskellPlatform # Haskell Platform 2012.2.0.0' nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform and you'll have profiles that contain the appropriate binaries and libraries defined by the corresponding platform. Nix can do this without any superuser privileges on Linux, Darwin, and BSD Unix, although I have to say that BSD support is limited because there seem to be very few people using Nix on BSD. (I reckon the BSD people are happy with their BSD ports and aren't interested in a third-party package manager.) Furthermore, Nix can many different versions of *any* package simultaneously, not just Haskell: nix-env -p ~/python-2.6.7 -iA python26 nix-env -p ~/python-2.7.3 -iA python27 nix-env -p ~/python-3.2.3 -iA python3 Anyone who's interested in Nix can find lots of information on the web site http://nixos.org/. There's also the IRC channel #nixos on irc.freenode.org where some Nix developers hang out. Last but not least, there is the developer mailing list nix-...@cs.uu.nl. I'll be happy to answer any further questions that may arise. Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Peter and Andres, Where is this functionality provided by Nix? simply run these commands ... # Haskell Platform 2012.2.0.0' nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform and you'll have profiles that contain the appropriate binaries and libraries defined by the corresponding platform. What you have here is a mechanism for setting up a user-environment for an appropriate platform. Unfortunately I cannot see how it can address any of the user-level Haskell package database management and sandboxing mechanisms that I mentioned in the announcement and subsequent emails. Also it requires that the user load up a special environment before going to work on a work tree rather than the drivers detecting from the context the correct toolchain and invoking it automatically. It might not sound like much but imagine how it would be if you had to set up a special environment before you could work with a git work tree -- there is quite a difference between the two approaches in practice. Finally the Nix method is of course fundamentally dependent upon Nix. I can appreciate why you may believe that everybody should just get Haskell through Nix but I think there is merit to developing a mechanism that allows Haskell to be better packaged regardless of its distribution channel. If I thought there was any chance at all that Haskell could be universally provided through Nix then it might be different, but I don't. None of which detracts from general excellence of Nix and the Nix Haskell distribution. And I still think the mechanism I am proposing would work well with the Nix distribution. Indeed it may be best placed to make full use of it. Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, I cannot see how it can address any of the user-level Haskell package database management and sandboxing mechanisms that I mentioned in the announcement and subsequent emails. have you ever actually used Nix? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
I deatiled some of my trials with Nix -- I wasn't making it up! Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
To be honest I did try to use Nix for exactly this purpose. For some reason things started to break and since I couldnt find any documentation on how to do stuff with it, I just abandonded the idea. Also tried out NixOS: pretty much the same story. Everything appears to be fine at the start, but then after few upgrades things start to fail. I know its very vague but really this is how I remember this experience. For one thing there was lack of how tos related to Haskell stuff anywhere. Just some general documentation that really have some gaps. You end up digging up some implementation details just because you wanted to install a new package. I'm not trying to spread FUD: only telling my not-so-success story with Nix. I'm sure Nix/NixOS has some potential but clearly it's not there yet for some reason. Best regards, Krzysztof Skrzętnicki On Fri, Jun 15, 2012 at 9:10 PM, Peter Simons sim...@cryp.to wrote: Hi Chris, I cannot see how it can address any of the user-level Haskell package database management and sandboxing mechanisms that I mentioned in the announcement and subsequent emails. have you ever actually used Nix? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
Hi Chris, I deatiled some of my trials with Nix -- I wasn't making it up! of course, I didn't mean to imply that you were. My question was phrased poorly, I am sorry. What I meant to ask is: how much time, approximately, did you spend working with Nix? 1 hour? 10 hours? 10 days? 10 months? Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
What I meant to ask is: how much time, approximately, did you spend working with Nix? 1 hour? 10 hours? 10 days? 10 months? You know that it is not 10 months, but I do object to your line of questioning. I have invested a considerable good-faith effort into getting to the bottom of what you and Andres have been saying. I am no seasoned expert at Nix but I have been through the process of installing and using multiple distributions, and reading around and I have been paying attention to what you have been saying. But my time is really quite limited. I of course know exactly what I have been doing in putting together the JustHub distribution and while they have some similarities -- mostly around the idea of allowing multiple tool chains to co-exist; the way they go about it is very different. And those details are critical in my mind (please note). I also know that I have been adding things that a generic package manager is most unlikely to be covering -- because a new tool is provided that tangles with the existing tools in a detailed way (e.g., parsing spec files and analysing package databases for example). To take just one example, I provide a mechanism that allows developers to archive the configuration of their Haskell development environment and check it into a source management system. The developer can check it out on a another system and if the build process invokes the recovery mechansim it will automatically rebuild the environment on the first run (reporting an error if the required tool chain is not installed on the system). Subsequent runs of the build process will merely check that nothing has been disturbed and proceed straight to the main build process. Maybe Nix provides such a mechanism -- I don't know. But all attempts to discover this and other mechanisms have failed and any hard information that I come across suggests that this is unlikely. (Hint: it is mostly concerned with the Haskell *user* package DB; I have just expanded on the 'archiving' part of the original announcement by the way.) It is a great shame as I like the Nix philsophy and I would like to see the other distributions adopt more of its functional philosophy. But I am out of time. If you will excuse me I would rather wind up this thread once you have replied (if you would like to) Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] JustHub 'Sherkin' Release
Chris Dornan wrote: The JustHub distribution is distinctive in providing a comprehensive back-catalogue of GHC tool chains (back to 6.10.4) and major Haskell Platform releases (currently back to 2011.2.0.1) as well as the timely appearance of leading edge GHC releases (such as GHC 7.4.2) in addition to the Haskell Platform de jour (2012.2.0.0), all of which can be deployed simultaneously on the same system. it might be of interest to know that the Nix package manager [1] offers that functionality too, but it can install such Haskell environments on all Linux variants and on MacOS X without requiring superuser privileges. BSD Unices probably work as well, but aren't tested as much as Linux/Darwin platforms, because there seems to be little demand for those. Take care, Peter [1] http://nixos.org/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] JustHub 'Sherkin' Release
On 14/06/12 18:36, Peter Simons wrote: it might be of interest to know that the Nix package manager [1] offers that functionality too, but it can install such Haskell environments on all Linux variants and on MacOS X without requiring superuser privileges. Is this actually the case? When I tried this a year or so ago I had lots of problems with Redhat Enterprise Linux 5, due to issues with it's quite old libc and kernel in that distribution. Most of the documentation at the nix website seems to relate to the nixos distribution, rather than using the nix packages on other, mainstream distributions. I'd love it if there we clear instructions on getting nix+packages up and running on RHEL. Tim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] JustHub 'Sherkin' Release
it might be of interest to know that the Nix package manager [1] offers that functionality too I am sorry if I gave the impression that JustHub was unique in adopting a functional philosophy to distributing Haskell -- obviously it is not and that was poor phrasing on my part. The key feature is the way it integrates the multiple tool chains into a single virtual tool chain with a sandboxing mechanism provided by the hub hackage. I think the Nix distribution might be a natural fit for 'hub' integration -- I would be happy to work with the Nix people on that (though it can't be right now). Chris ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] JustHub 'Sherkin' Release
Hi Tim. Nix can install such Haskell environments on all Linux variants and on MacOS X without requiring superuser privileges. Is this actually the case? Yes. When I tried this a year or so ago I had lots of problems with Redhat Enterprise Linux 5, due to issues with it's quite old libc and kernel in that distribution. CentOS used to ship patched kernels that break modern versions of glibc. I'm not sure whether that problem still exists today, but if it does, then it can be worked around by having Nix build things with an sufficiently old glibc. I used to do that for quite a while, but fortunately I got rid of these ancient installations, so I haven't tried it recently. Anyway, if you're having trouble using Nix, you're welcome to contact me by e-mail (or the nix developers mailing list). Maybe we can sort these problems out. Take care, Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] JustHub 'Sherkin' Release
Hi Chris. The key feature is the way it integrates the multiple tool chains into a single virtual tool chain with a sandboxing mechanism provided by the hub hackage. I think the Nix distribution might be a natural fit for 'hub' integration -- I would be happy to work with the Nix people on that (though it can't be right now). If this adds anything in terms of functionality that Nix doesn't already provide, then I would be interested to know. From having a quick look at your announcements, it's not quite clear though if it does. Cheers, Andres ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
[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
[Haskell] JustHub 'Sherkin' Release
JustHub 'Sherkin' Release I am pleased to announce the Sherkin release of the JustHub distribution of Haskell for Enterprise Linux and the release of the Hub source code on which the distribution is based to Hackage and GitHub. The JustHub distribution is distinctive in providing a comprehensive back-catalogue of GHC tool chains (back to 6.10.4) and major Haskell Platform releases (currently back to 2011.2.0.1) as well as the timely appearance of leading edge GHC releases (such as GHC 7.4.2) in addition to the Haskell Platform de jour (2012.2.0.0), all of which can be deployed simultaneously on the same system. Previous releases of the distribution have been confined to Red Hat Enterprise Linux versions 5 and 6 (and of course CentOS and Scientific Linux); this release expands this coverage to Fedora Linux 16 and 17, which can deployed along side or integrated into Fedora Linux's excellent native Haskell distribution. 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. If anyone would like to incorporate the hub system into a Haskell distribution or port it to a non-Posix system then they are very welcome to contact me (though be warned: time is tight just now). Note that while the distro has had plenty of serious usage (funnily enough it is popular with build-bot admins) it has also been recently extended and revised the software remains in beta testing for now. For news, documentation, articles, download and installation instructions, links to the repositories and trackers etc., see http://justhub.org. Chris Dornan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
