We had a few "overrides" in configuration-common.nix that were really
extensions. They introduced packages that weren't in hackage-packages.nix.
The advantage of having a dedicated file for these packages is that we can still
place Nix-specific overrides to these packages in configuration-nix.nix. We
weren't able do this before because configuration-nix.nix extended only the
packages from hackage-packages.nix.
- The haskell lib is very close to not relying on Nixpkgs. I think
this is good---simpler to think about and matches Nixpkgs's lib.
- The haskell lib is only imported once
- stdenv is exposed more shallowly so it can be overriden more easily.
I'll eventually use this on Darwin to avoid the Sierra shared
library problems (unless changes are to be made system-wide).
Closes https://github.com/NixOS/nixpkgs/pull/27840.
The motivation is to be able to get rid of common configuration
when initial packages differs since common configuration assumes
a very specific version set.
cc @jmitchell @peti
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.
