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 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
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
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
Hi Peter and Andres, 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
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
I deatiled some of my trials with Nix -- I wasn't making it up! Chris
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
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
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
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
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
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
[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
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
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
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
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
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 "stateful").
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),
Yes. This is what you get with Nix(OS).
or equivalently use intelligent drivers that make sure the right tools get invoked (the method JustHub uses).
Ok.
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.
Not a problem in Nix(OS) either. Indeed, for each compiler version I have standard "plain" and "platform" profiles installed on my machine, with just the GHC-provided or just the platform packages. In addition, I then have project-specific profiles. The packages, as far as they're contained in several profiles, are installed only once and shared via the Nix store.
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
Right. That's why in Nix(OS) we currently don't try to actually patch cabal-install or other tools to behave differently from normal. So you're free to use for example cabal-dev on top of a NixOS profile, but in order to benefit from NixOS fully, you should install Haskell packages via Nix. We have tools that try to make it easy to add new packages to the Nixpkgs collection semi-automatically, but admittedly, that's not quite as simple as typing "cabal install".
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.
Let me say again that I'm curious to learn the differences. Thanks for taking the time to explain this to me, as I haven't had the time to work with JustHub yet, and it certainly looks very interesting. I'm *not* trying to dismiss JustHub as being useless. OTOH, there's certainly overlap between the two systems. So if we're ever thinking of integrating one into the other, I'd like to make sure that there isn't too much redundancy.
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.
I never said that.
Finally a couple of gripes with Nix as a replacement for JustHub. [...]
I also never suggested that, at least not in general. If anything, I'd say that people interested in JustHub might also be interested to look at Nix(OS).
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.
NixOS is a community project that the moment, there's no official definition of "support". In practice, we have GHC versions 6.10.4, 6.12.1, 6.12.2, 6.12.3, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2, 7.4.1, 7.4.2 and HEAD (snapshot). There's no restriction to platform releases. Cheers, Andres
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
participants (4)
-
Andres Löh -
Chris Dornan -
Krzysztof Skrzętnicki -
Peter Simons