extensible-exceptions actually is a core library. It wasn't in ghc-6.10, though. I'm not sure what to do here: either remove it as a core package, consequently include it where it's a dependency, but set it to null for all newer GHCs. Or drop support for ghc-6.10 completely, and keep it as a core package.

cabal2nix should generate expressions that are parametrized the same way Cabal builds are. There may be a number of boolean flags that enable/disable additions features (and also change the set of required build inputs).

The build of yesod-core-0.9.2 fails in http://hydra.nixos.org/build/1344465/nixlog/1/raw with the following error:

[ 5 of 15] Compiling Yesod.Internal   ( Yesod/Internal.hs, dist/build/Yesod/Internal.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bytestring-0.9.2.0 ... linking ... done.
Loading package array-0.3.0.3 ... linking ... done.
Loading package containers-0.4.1.0 ... linking ... done.
Loading package deepseq-1.1.0.2 ... linking ... done.
Loading package text-0.11.1.5 ... linking ... done.
Loading package blaze-builder-0.3.0.1 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package enumerator-0.4.14 ... linking ... done.
Loading package blaze-builder-enumerator-0.2.0.2 ... linking ... done.
Loading package hashable-1.1.2.1 ... linking ... done.
Loading package case-insensitive-0.3.0.1 ... linking ... done.
Loading package filepath-1.2.0.1 ... linking ... done.
Loading package old-locale-1.0.0.3 ... linking ... done.
Loading package old-time-1.0.0.7 ... linking ... done.
Loading package unix-2.5.0.0 ... linking ... done.
Loading package directory-1.1.0.1 ... linking ... done.
Loading package http-types-0.6.5.1 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package parsec-3.1.1 ... linking ... done.
Loading package network-2.3.0.5 ... linking ... done.
Loading package time-1.2.0.5 ... linking ... done.
Loading package wai-0.4.2 ... linking ... done.
Loading package zlib-0.5.3.1 ... <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)

This appears to be a problem with the latest version of haskell-zlib. Curiously enough, the package propagates zlib, so the load path should be available at compile-time.

SDL-image lacks 'SDL_image'.
SDL-ttf lacks 'SDL_ttf'.
SDL-mixer lacks 'SDL_mixer'.

We probably need to patch the Cabal file.

github for example makes tarballs associated with tags available over https only.

GLURaw ends up having a dependency on mesa, which is apparently not correct?

Cabal produces a flag assignment for every package. We don't include those flags in the configurePhase, though, so these choices aren't visible to users (and they aren't deterministic).

The downside of including the default flag assignment in the expression is that we need to generate separate expressions for separate compilations environments, i.e. the flags chosen for a GHC 7.6.3 build may vary from those chosen for GHC 6.10.4. Right now, these choices happen transparently at build-time.

An example of the file format is at: http://people.debian.org/~nomeata/cabalDebianMap.txt.

With a default install of Ceh, hoogle appears to be broken. It will install fine, but then it needs to fetch data and cannot because the store is read only:

$ hoogle data
hoogle: /nix/store/w6lwbndblqn4ax3gl6agqm0l0slwkfgi-haskell-hoogle-ghc7.6.3-4.2.19-profiling/share/hoogle-4.2.19/databases: createDirectory: permission denied (Permission denied)

I am on Ubuntu 12.04 if that is important, and am happy to provide any other information that is useful.

$ uname -a
Linux owl 3.5.0-32-generic #53-Ubuntu SMP Wed May 29 20:23:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I wrote the following little FAQ: http://wiki.ocharles.org.uk/Nix#how-do-i-use-cabal2nix-for-local-projects. I get asked this a lot, and the process is entirely mechanical - so I feel this is something that could go into cabal2nix.

@peti, if you agree this is useful - where would you put it?

I'm adding the new GHC version right now ...

This needs support in cabal2nix as well.

Hipmunk depends on the 'm' library, which is a part of stdenv and does not need to be mentioned explicitly. The same applies to the "stdc++" library, which double-conversion requires in its Cabal file, if I remember correctly.

The bits-extra package has gcc_s in extra-libraries field. What cabal2nix does is put gcc_s as an extra argument and makes extraLibraries = [ gcc_s ];, which doesn't work because such package doesn't exist. I am told that it instead needs to do something with NIX_LDFLAGS="-lgcc_s" and have gcc as a dependency.

The coding guidelines for Nix say:

Function formal arguments are written as:

{ arg1, arg2, arg3 }:

Cabal2nix, however, adds a blank before the colon, the rationale being that it is a binary operator, and it's really common practice to have binary operators separated by blanks.

It's not possible to use ghcWithPackages to generate a GHC 6.10.4 environment because the old ghc-pkg binary doesn't know about the recache action. I tried patching the script so that it just won't call that command, but that didn't help, because apparently GHC 6.10.4 doesn't have the ability to read a package.conf.d directory either.

Right now, everythings that's mentioned in the Cabal file becomes a propagatedBuildInput. There are dependencies, however, that don't need to be propagated, namely

• build-tools (like cpphs, happy) and
• libraries used in building executable-only projects.

Some Cabal files get their dependencies wrong, i.e. SDL-{image,ttf,mixer}. We need a way to fix that. We could:

• allow manipulation of the build inputs via command line (i.e. adding, dropping, or re-writing names), or
• allow a standard patch to be applied to the Cabal file before it's being processed.

The patch solution is clearly the most powerful one, and it's easily implemented, too. It's also totally out-of-scope for cabal2nix. It feels a little ridiculous to have cabal2nix run patch for the user instead of having users feed a patched cabal file to cabal2nix to begin with. (Of course, that feature can be nice when fetching Cabal files via HTTP.) Maybe pactches ought to be dealt with in hackage4nix?

[shana@lenalee:~/programming/nix-project-defaults/tsuntsun]$ ~/c2n file:///home/shana/programming/tsuntsun/tsuntsun.cabal  > default.nix
*** cannot compute hash. (Not a hackage project?)
 Specify hash explicitly via --sha256 and add appropriate "src" attribute
 to resulting nix expression.

[shana@lenalee:~/programming/nix-project-defaults/tsuntsun]$ ~/c2n file:///home/shana/programming/tsuntsun/tsuntsun.cabal --sha256 nil  > default.nix
*** cannot compute hash. (Not a hackage project?)
 Specify hash explicitly via --sha256 and add appropriate "src" attribute
 to resulting nix expression.

I suspect the local patches PR broke this. It does not work if I just specify the path either which is what I thought it would let me do. Perhaps bitrot got it when rebasing.

cc @bennofs

In order to install or build packages I have found it necessary to create and install a custom environment. ar which comes with stdenv is needed for most builds. I think I included zlib glibc and pkgconfig to build gtk bindings at some point though I no longer remember if each was critical.

packageOverrides = pkgs :with pkgs; rec {
cabalEnv = pkgs.myEnvFun {
name = "cabal";
buildInputs = [ stdenv zlib glibc pkgconfig ];
};

I did not see this mentioned elsewhere so I thought I should let you know. Let me know if any other information is needed.

How about calling that nixos-types?

Not specified in the Cabal file.

Maybe cabal2nix should have a flag that enables this behavior in the generated output?

Alternatively, the generated expression could accept a function parameter to enable/disable that behavior.

Currently, patching seems to be hardcoded.

However, a large part of the current philosophy of hackage4nix is based on "regenerating what's currently there". I'm actually starting to like that philosophy. So I'd like to make patching modular enough so that hackage4nix can parse package descriptions, understand how exactly it has been patched, and maintain the patch after regeneration. Of course, this won't work for arbitrary modifications of the generated file, but it should work for many common cases (extra attributes, specifying flag settings).

Missing in the Cabal file.

Consider https://github.com/fumieval/free-game/blob/master/free-game.cabal

It has a dependency on GLFW-b and it translates according to the usual rules: dashes get removed and following letter capitalised. It seems to be a convention that a single letter followed by the dash should not be capitalised: in fact, haskell-packages.nix packages that dependency as GLFWb.

Seems like there either needs to be ammendment on cabal2nix side or the convention needs to be adjusted on nixpkgs side.

Trying to convert Euterpea.cabal
Conversion fails with this:

$ cabal2nix file:///home/danbst/hs/Euterpea/Euterpea.cabal
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found
/nix/var/nix/profiles/default/bin/nix-prefetch-url: download of ‘http://hackage.haskell.org/packages/archive/Euterpea/1.0.0/Euterpea-1.0.0.tar.gz’ failed
cabal2nix: readProcess: bash "-c" "exec nix-prefetch-url 2>/dev/tty http://hackage.haskell.org/packages/archive/Euterpea/1.0.0/Euterpea-1.0.0.tar.gz" (exit 22): failed

Found reason - if --sha256 is not specified, it tries to compute it and downloads package from hackage

module Cabal2Nix.Hackage ( hashPackage, readCabalFile ) where
...
hashPackage :: PackageIdentifier -> IO String
hashPackage pkg = do
    cachePath <- hashCachePath pkg
    exists <- doesFileExist cachePath
    hash' <- if exists
               then readFile cachePath
               else readProcess "bash" ["-c", "exec nix-prefetch-url 2>/dev/tty " ++ hackagePath pkg TarGz] ""

What is the correct way to handle this situation?

The filtering code in directory traversal is too eager.

This was recently removed. I added it again.

Some packages still depend on the network-bytestring package, but that package no longer exists as a separate entity. Its functionality is now part of network, so we shouldn't depend on network-bytestring, even if the Cabal file says that we should.

You know that ultimately, I'd like to generate (parts of) haskell-packages.nix automatically, too. While in principle, it's possible to do that even if packages reside in various directories throughout nixpkgs, I think that in practice, it just makes things harder without serving much of a benefit. For most other languages X there is now a directory development/X-modules, so perhaps we should create development/haskell-modules and move everything there? (I don't like the name -modules much for Haskell stuff, so perhaps development/haskell-packages is even better.)

A single name in Cabal may map to a list of attributes in Nix. A neat side effect is that mapping "foo" to [] allows us to ignore dependencies, too.

Let's avoid convoluted double negation of setting noHaddock = true to express haddock = false.

The repa maintainers have released 2.1.1.5, which works with ghc 7.0.4 and earlier. Also, there is version 2.1.1.6, which works with ghc 7.2 and newer. Now, how can we support this setup?

The obvious solution would be:

# Version 2.1.1.5 is intended for ghc <7.2, and version 2.1.1.6 is for the newer GHC.
repa_2_1_1_5 = callPackage ../development/libraries/haskell/repa/2.1.1.5.nix {};
repa_2_1_1_6 = callPackage ../development/libraries/haskell/repa/2.1.1.6.nix {};
repa = self.repa_2_1_1_5;

This is confusing, though, because nix-env -i is always going to pick the latest version. Also, a derivation like repaExamples is not going to work on 7.2.1 either, without further overrides in haskellPlatformDefaults_future.

An alternative is:

repa = if "${ghc.version}" == "7.2.1"
         then (callPackage ../development/libraries/haskell/repa/2.1.1.6.nix {})
         else (callPackage ../development/libraries/haskell/repa/2.1.1.5.nix {});

That works fine, but it doesn't work for ghcHEAD. We could add more version numbers into that check, of course, but that feels like an approach that won't scale.

We might be able to rescue that previous approach by adding a flag to the GHC expression, say "base_4_4 = true" for >=7.2 and "base_4_4 = false" for the older ones.

Let me know if there is any other info need.

$ nix-env -iA nixos.pkgs.myHaskellPackages.iterateeCompress --option build-use-substitutes false --vvv

can be found at:
http://hpaste.org/80849

$ nix-env -iA nixos.pkgs.myHaskellPackages.iterateeCompress --option build-use-substitutes false --show-trace
installing haskell-iteratee-compress-ghc7.4.2-0.3.3.0' error: while evaluating the builtin functionderivationStrict':
while instantiating the derivation named haskell-iteratee-compress-ghc7.4.2-0.3.3.0' at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/build-support/cabal/default.nix:36:13':
while evaluating the derivation attribute propagatedBuildNativeInputs' at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/stdenv/generic/default.nix:69:15':
while evaluating the function at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:136:21': while evaluating the attributepropagatedBuildInputs' at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/build-support/cabal/default.nix:20:17': while evaluating the function at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:84:12':
while evaluating the function at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:28:19': while evaluating the function at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:85:16':
while evaluating the function at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:28:19': while evaluating the function at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:85:16':
while evaluating the function at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:28:19': while evaluating the function at/nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/lib/lists.nix:85:16':
while evaluating the function at /nix/store/ivnjbpksshmh10d6c3gsk2aa32lwxpk8-nixos-0.1pre4014_78bd54c-f0997b9/nixos/nixpkgs/pkgs/build-support/cabal/default.nix:20:60': while evaluating the builtin functionhead':
attribute `bz2' missing

Importatnt part of config.nix

myHaskellPackages = 
  let callPackage = pkgs.lib.callPackageWith myHaskellPackages; in
    pkgs.recurseIntoAttrs (pkgs.haskellPackages.override {
      extraPrefs = self : with pkgs ; rec {

        zoomCache = callPackage ./haskell/zoom-cache {};
        scope     = callPackage ./haskell/scope {};
        scopeCairo = callPackage ./haskell/scope-cairo {};
        iterateeCompress = callPackage ./haskell/iteratee-compress {
          bz2 = pkgs.bz2;
        };
        typeLevel = callPackage ./haskell/type-level {};
        uiCommand = callPackage ./haskell/ui-command {};
      };
    });

See bitarray package, hackage4nix should pick up that 0.0.1.1 is an update but it doesn't seem to.

persistent-0.6.1 declares Extra-Libs in its test-suite stanza, and it seems that cabal2nix doesn't pick that up.

I contacted upstream and asked for an update. If that update doesn't materialize within a few days, we'll have to downgrade cpphs again, though.

The first dictionary defines text version 0.11.1.5. The second, however, defines text version 0.11.1.9. Is that intentional?

But it used to. Not sure yet what's going on ...

I changed the ~/.cabal/config file for a fast hackage mirror, so there is no ~/.cabal/hackage.haskell.org/ there. Then cabal2nix will give an error when I try cabal2nix cabal://somepackage.

What can I do?

This problem is similar to the issue with extensible-extensions. time is now a core library, and it shouldn't be necessary to depend explicitly on it.

The following command fails for no apparent reason:

$ cabal2nix cabal://git-annex
*** cannot compute hash. (Not a hackage project?)
 If your project is not on hackage, please supply the path to the root directory of
 the project, not to the cabal file.

 If your project is on hackage but you still want to specify the hash manually, you
 can use the --sha256 option.

@bennofs, is this maybe related to your recent changes? The SHA logic was changed recently, right?

I had to set noHaddock=true manually in order to get transformers-compact-0.1 to install correctly. With out modifying the transformers-compact-0.1 nix expression a build would complain that no file was provided for haddock which was the clue to put noHaddock=true;

This library is required for for len-7.3 which is currently the most recent version on hackage.

GHC 7.2.2 won't compile it's haskellPlatform attribute because haddock 2.10.0 requires GHC 7.4 or later. I've tried to remedy that issue somehow, but I couldn't manage. :-(

This is related to the mail I've sent on the nix-dev mailing list. I've now looked at the recent changes and must say that I strongly disagree with the new handling of Cabal.

There are a number of issues:

(1) Removing so-called "core packages". I think that's fine as long as it's possible to still obtain the original configuration shipped with a particular GHC version. So in that sense, promoting Cabal to a normal package is fine with me.

(2) Adding Cabal as an explicit dependency to all packages. This is what I think is wrong. It is not. Packages use Cabal as their build system, but it's not comparable to other package dependencies. The "buildDepends" field should reflect the actual build dependencies. The "correct" way to deal with this would be to pass Cabal to cabal (note the spelling difference) only, because that's the function that governs how Haskell packages are being built.

Apart from these two points, I'm still trying to figure out what triggered this particular change.

We need to escape them, strip them, or quote the description in ''...''.

Packages that don't include a library aren't detected in the output from "nix-env -qa *". I guess, it would be better to try and recognize the "haskellPackages" part of the attribute instead.

Running cabal2nix on http://hackage.haskell.org/package/darcs-2.8.4/darcs.cabal doesn't produce unix as one of the dependencies.