This change is effectively a no-op to nixpkgs. However, it gives users
the flexibility to create and maintain their own package sets per
project, while benefiting from nix's Haskell configurations.
I would make immediate use of this change in stack2nix, a project that
generates nix expressions for all the dependencies of a given Haskell
project. @domenkozar is familiar with the motivations and helped
refine this change
Allows using a different haskell package set to generate the nix
expressions (during eval time) than the one used to actually build the
package (at build time).
As per the recommendation by @Mathnerd314, this change seems to work
with the testing I did.
It makes sense to me why it works, but I think it's in an important
enough place that someone with much deeper knowledge of Haskell
infrastructure in Nixpkgs should give it a really heavy review.
I also consolidated all the overrideCabal definitions (there were two)
into a single definition in haskell-modules/lib.nix.
The callCabal2nix function cannot reliably determine the appropriate "name" for
the package it's processing. Attempts to derive this information have led to
plenty of evaluation errors, and so I'd like to go for the obvious and reliable
solution now and let the caller specify that bit of information.
Here is an example that demonstrates how to use callCabal2nix.
let
pkgs = import <nixpkgs> {};
src = pkgs.fetchFromGitHub {
owner = "gtk2hs";
repo = "gtk2hs";
rev = "eee61d84edf1dd44f8d380d7d7cae2405de50124";
sha256 = "12i53grimni0dyjqjydl120z5amcn668w4pfhl8dxscjh4a0l5nb";
};
in
pkgs.haskellPackages.callCabal2nix "gtkhs-tools" "${src}/tools" {}
This commit changes callHackage to use a deterministic version of the Hackage
checkout from https://github.com/commercialhaskell/all-cabal-hashes by default.
This means that packages uploaded to Hackage after today will be available to
callHackage only after "pkgs/data/misc/hackage/default.nix" has been updated.
People who want the previous behavior where we always had the latest version of
Hackage available -- at the cost of frequent downloads from Github --, can add
the following override to their "~/.nixpkgs/config.nix" file:
{
packageOverrides = super: {
all-cabal-hashes = builtins.fetchTarball "https://github.com/commercialhaskell/all-cabal-hashes/archive/hackage.tar.gz";
};
}
The function "callHackage <name> <version>" generates build instructions for
the requested library version on-the-fly. All of Hackage is available. Note:
this code is brand-new, experimental, and it might change in the future. Don't
base production code on this feature yet.
Example usage:
$ nix-shell -p 'haskellPackages.callHackage "cpphs" "1.19.3" {}' --run "cpphs --version"
cpphs 1.19.3
$ nix-shell -p 'haskellPackages.ghcWithPackages (self: [(self.callHackage "hsdns" "1.6.1" {})])' --run "ghc-pkg list hsdns"
/nix/store/p6r81k2vb2pzy4wcvri6z9m492i0hg63-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d
hsdns-1.6.1
These functions used to live in pkgs/development/haskell-modules/default.nix,
but they are generic, really, and should be easily accessible to everyone.
This update was generated by hackage2nix v20150903-82-g351b6f8 using the following inputs:
- Hackage: af161fdf17
- LTS Haskell: da73308b63
- Stackage Nightly: 1994a4f865
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
With this patch applied, "nix-env -qaP -A haskellngPackages" succeeds fine
without running out of memory. Thanks to @bennofs for catching this in
bbb422af92 (commitcomment-11235596).
Build environments created by overrideScope lost the ability to find
packages outside of the Haskell package set without help. This patch
remedies this issue.
Fixes https://github.com/NixOS/nixpkgs/issues/6192.
This makes the attribute (a) consistent with "doCheck" and friends and (b)
avoids the double negation "noHaddock = false" meaning "doHaddock = true".
Fixes https://github.com/NixOS/cabal2nix/issues/63.
deepOverride turns out to be completely unfeasible for non-trivial overrides.
Nix evaluates for an eternity, and then comes back saying:
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
nix-instantiate killed by signal 6
The hand-written deep-override, on the other hand, performs the job in a
fraction of a second, no problem.
All bow to Russell O'Connor!
