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