nixos / cabal2nix Goto Github PK
View Code? Open in Web Editor NEWGenerate Nix build instructions from a Cabal file
Home Page: https://haskell4nix.readthedocs.io
License: Other
Generate Nix build instructions from a Cabal file
Home Page: https://haskell4nix.readthedocs.io
License: Other
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 function
derivationStrict':
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 attribute
propagatedBuildInputs' 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 function
head':
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 {};
};
});
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.
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. :-(
The filtering code in directory traversal is too eager.
This needs support in cabal2nix as well.
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.
This was recently removed. I added it again.
GLURaw
ends up having a dependency on mesa
, which is apparently not correct?
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?
How about calling that nixos-types?
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.
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.
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.
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.
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.
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.
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.
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.
Missing in the Cabal file.
Let's avoid convoluted double negation of setting noHaddock = true
to express haddock = false
.
I'm adding the new GHC version right now ...
persistent-0.6.1 declares Extra-Libs in its test-suite stanza, and it seems that cabal2nix doesn't pick that up.
The first dictionary defines text
version 0.11.1.5. The second, however, defines text
version 0.11.1.9. Is that intentional?
[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
Not specified in the Cabal file.
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.
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.)
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).
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?
An example of the file format is at: http://people.debian.org/~nomeata/cabalDebianMap.txt.
But it used to. Not sure yet what's going on ...
github for example makes tarballs associated with tags available over https only.
See bitarray
package, hackage4nix should pick up that 0.0.1.1 is an update but it doesn't seem to.
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.
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).
SDL-image lacks 'SDL_image'.
SDL-ttf lacks 'SDL_ttf'.
SDL-mixer lacks 'SDL_mixer'.
We need to escape them, strip them, or quote the description in ''...''.
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.
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.
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.
We probably need to patch the Cabal file.
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.
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
Running cabal2nix on http://hackage.haskell.org/package/darcs-2.8.4/darcs.cabal doesn't produce unix
as one of the dependencies.
Some Cabal files get their dependencies wrong, i.e. SDL-{image,ttf,mixer}. We need a way to fix that. We could:
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?
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 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?
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 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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.