Re: [Nix-dev] Haskell NG
Peter Simons cryp.to> writes: Links 1 and 2 are dead. > Best regards, > Peter > > [1] https://github.com/peti/nixpkgs/tree/haskell-ng > [2] https://github.com/NixOS/cabal2nix/tree/v2.x > [3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng / cabal-install problem
Hi Tobias, What I need is cabal 1.20.x because I would like to use ghc-mod which is not compatible with 1.22.x because of a file format change in cabal leading to ghc-mod being unable to parse. We don't have cabal-install 1.20.x. There is cabal-install 1.18.x, though, which is the latest version GHC 7.8.x can compile with its own core libraries: $ nix-env -qaP -A haskell.packages.ghc784 cabal-install haskell.packages.ghc784.cabal-install_1_18_0_8 cabal-install-1.18.0.8 haskell.packages.ghc784.cabal-install cabal-install-1.22.3.0 Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng / cabal-install problem
Hi Tobias, I would like to use ghc 7.8.4 and cabal-install 1.20.x. what Nixpkgs branch are you on? The current 'master' branch (a.k.a. 'nixos-unstable' channel) has cabal-install 1.22.x, and it builds fine: $ nix-build nixpkgs -A haskell-ng.packages.ghc784.cabal-install /nix/store/p6wh37rmnmx74qbm7rrpbr7rna95wqkz-cabal-install-1.22.3.0 Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskell-ng / cabal-install problem
Hi, I've been facing some problems with haskell-ng and cabal-install. I would like to use ghc 7.8.4 and cabal-install 1.20.x. I try to install cabal-install as follows: $ nix-env -f ~/nixpkgs -i -A haskell-ng.packages.ghc784.cabal-install The build fails because of missing dependencies : [1 of 1] Compiling Main ( Setup.hs, /tmp/nix-build-cabal-install-1.20.0.3.drv-0/Main.o ) Linking Setup ... configuring configureFlags: --verbose --prefix=/nix/store/rzlbizs8c173gby60hvdmhzdln7n60bb-cabal-install-1.20.0.3 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-cabal-install-1.20.0.3.drv-0/package.conf.d --ghc-option=-optl=-Wl,-rpath=/nix/store/rzlbizs8c173gby60hvdmhzdln7n60bb-cabal-install-1.20.0.3/lib/ghc-7.8.4/cabal-install-1.20.0.3 --ghc-option=-j4 --enable-split-objs --disable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --disable-tests Configuring cabal-install-1.20.0.3... Setup: At least the following dependencies are missing: Cabal =1.20.0 1.21, network =2.0 2.6, random =1 1.1 builder for ‘/nix/store/bjpwinfa70cw6yxvbzxj8qv1zk18iyid-cabal-install-1.20.0.3.drv’ failed with exit code 1 error: build of ‘/nix/store/bjpwinfa70cw6yxvbzxj8qv1zk18iyid-cabal-install-1.20.0.3.drv’ failed What am I doing wrong ? How can I get this to work ? thanks, Tobi PS: I'm running nix on Ubuntu. Tracking nixpkgs via NixOS/nixpkgs-channels ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng / cabal-install problem
On 07.05.2015 21:22, Peter Simons wrote: nix-build nixpkgs -A haskell-ng.packages.ghc784.cabal-install What I need is cabal 1.20.x because I would like to use ghc-mod which is not compatible with 1.22.x because of a file format change in cabal leading to ghc-mod being unable to parse. So how can I install cabal-install 1.20.x? I am on nixpkgs master now as well. regards, Tobi ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell NG: Local packages
Hello fellow Haskellers,
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect dependencies between them. My current solution is ad hoc
and rather ugly. I'm using the following hand-crafted `shell.nix` file
in every project:
{ pkgs ? import nixpkgs {} }:
let inherit (pkgs.haskellngPackages) callPackage;
extPkg = path: deps:
(callPackage (import path) deps).override (args: args // {
mkDerivation = expr:
args.mkDerivation (expr // {
src = pkgs.fetchdarcs { url = path; };
});
});
thisPkg = callPackage (import ./devel.nix) {
direct-dep1 = extPkg ertes-src/dep1/main {
indirect-dep1 = ...;
indirect-dep2 = ...;
};
direct-dep2 = extPkg ertes-src/dep2/main {};
};
in thisPkg.env
Do not pay too much attention to the `extPkg` function. It just works
around cabal2nix' lack of support for Darcs URLs.
My question is: Is there a nicer and more principled way to solve this?
Ideally I could simply add all of my local packages in some way to my
`~/.nixpkgs/config.nix`. Then they could just depend on each other
regularly and I wouldn't need any shell.nix hackery. I'm guessing that
I need to override haskellngPackages in some way or perhaps create my
own using some override.
Greets,
Ertugrul
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Local packages
I believe Peter's message 87mw5qvj9x@write-only.cryp.to could
answer my question. I will give it a try.
Hello fellow Haskellers,
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect dependencies between them. My current solution is ad hoc
and rather ugly. I'm using the following hand-crafted `shell.nix` file
in every project:
{ pkgs ? import nixpkgs {} }:
let inherit (pkgs.haskellngPackages) callPackage;
extPkg = path: deps:
(callPackage (import path) deps).override (args: args // {
mkDerivation = expr:
args.mkDerivation (expr // {
src = pkgs.fetchdarcs { url = path; };
});
});
thisPkg = callPackage (import ./devel.nix) {
direct-dep1 = extPkg ertes-src/dep1/main {
indirect-dep1 = ...;
indirect-dep2 = ...;
};
direct-dep2 = extPkg ertes-src/dep2/main {};
};
in thisPkg.env
Do not pay too much attention to the `extPkg` function. It just works
around cabal2nix' lack of support for Darcs URLs.
My question is: Is there a nicer and more principled way to solve this?
Ideally I could simply add all of my local packages in some way to my
`~/.nixpkgs/config.nix`. Then they could just depend on each other
regularly and I wouldn't need any shell.nix hackery. I'm guessing that
I need to override haskellngPackages in some way or perhaps create my
own using some override.
Greets,
Ertugrul
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Local packages
I believe Peter's message 87mw5qvj9x@write-only.cryp.to could
answer my question. I will give it a try.
It does and works well. Thanks anyway!
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect dependencies between them. My current solution is ad hoc
and rather ugly. I'm using the following hand-crafted `shell.nix` file
in every project:
{ pkgs ? import nixpkgs {} }:
let inherit (pkgs.haskellngPackages) callPackage;
extPkg = path: deps:
(callPackage (import path) deps).override (args: args // {
mkDerivation = expr:
args.mkDerivation (expr // {
src = pkgs.fetchdarcs { url = path; };
});
});
thisPkg = callPackage (import ./devel.nix) {
direct-dep1 = extPkg ertes-src/dep1/main {
indirect-dep1 = ...;
indirect-dep2 = ...;
};
direct-dep2 = extPkg ertes-src/dep2/main {};
};
in thisPkg.env
Do not pay too much attention to the `extPkg` function. It just works
around cabal2nix' lack of support for Darcs URLs.
My question is: Is there a nicer and more principled way to solve this?
Ideally I could simply add all of my local packages in some way to my
`~/.nixpkgs/config.nix`. Then they could just depend on each other
regularly and I wouldn't need any shell.nix hackery. I'm guessing that
I need to override haskellngPackages in some way or perhaps create my
own using some override.
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Local packages
It's not specific to Haskell (and I haven't tried haskellng at all yet) but for
personal packages I have mypkgs/pkgname/default.nix, and then a top-level
mypkgs/default.nix:
let
nixpkgs = import nixpkgs {};
callPkg = nixpkgs.newScope
( nixpkgs
// nixpkgs.haskellPackages
// nixpkgs.python27Packages
// self
);
self = {
canonicalFilepath = callPkg ./canonical-filepath {} ;
filestore = callPkg ./filestore {} ;
gitit = callPkg ./gitit {} ;
igv = callPkg ./igv{} ;
igvtools = callPkg ./igvtools {} ;
indentparser = callPkg ./indentparser {} ;
jeffkb= callPkg ./jeffkb {} ;
jeffwiki = callPkg ./jeffwiki {} ;
ncbi-blast= callPkg ./ncbi-blast {} ;
rPackages = callPkg ./r-modules {} ;
scan2pdf = callPkg ./scan2pdf {} ;
scripts = callPkg ./scripts{} ;
tarql = callPkg ./tarql {} ;
tasktree = callPkg ./tasktree {} ;
tsync = callPkg ./tsync {} ;
};
in (nixpkgs // self)
I add that to my NIX_PATH so I can `import mypkgs` anywhere to get nixpkgs
overridden with the stuff I'm working on.
Jeff
On Tue, 28 Apr 2015 22:11:57 +0200
Ertugrul Söylemez ert...@gmx.de wrote:
I believe Peter's message 87mw5qvj9x@write-only.cryp.to could
answer my question. I will give it a try.
Hello fellow Haskellers,
I have a bunch of local Haskell packages, mostly libraries. The package
X lives in the directory `ertes-src/X/main`. There are lots of direct
and indirect dependencies between them. My current solution is ad hoc
and rather ugly. I'm using the following hand-crafted `shell.nix` file
in every project:
{ pkgs ? import nixpkgs {} }:
let inherit (pkgs.haskellngPackages) callPackage;
extPkg = path: deps:
(callPackage (import path) deps).override (args: args // {
mkDerivation = expr:
args.mkDerivation (expr // {
src = pkgs.fetchdarcs { url = path; };
});
});
thisPkg = callPackage (import ./devel.nix) {
direct-dep1 = extPkg ertes-src/dep1/main {
indirect-dep1 = ...;
indirect-dep2 = ...;
};
direct-dep2 = extPkg ertes-src/dep2/main {};
};
in thisPkg.env
Do not pay too much attention to the `extPkg` function. It just works
around cabal2nix' lack of support for Darcs URLs.
My question is: Is there a nicer and more principled way to solve this?
Ideally I could simply add all of my local packages in some way to my
`~/.nixpkgs/config.nix`. Then they could just depend on each other
regularly and I wouldn't need any shell.nix hackery. I'm guessing that
I need to override haskellngPackages in some way or perhaps create my
own using some override.
Greets,
Ertugrul
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Local packages
Hi Jeff,
I'm using a similar approach for non-Haskell packages. However, for
Haskell packages it doesn't interact well with cabal2nix. Hence my
question. I have now solved it the following way in
`~/.nixpkgs/config.nix`:
haskellPackageOverrides = self: super:
let asDarcs = path:
(self.callPackage (import path) {}).override (args: args // {
mkDerivation = expr:
args.mkDerivation (expr // {
src = nixos.pkgs.fetchdarcs { url = path; };
});
});
in {
myxmonad = self.callPackage ertes-config/myxmonad {};
mytaffybar = self.callPackage ertes-config/mytaffybar {};
testpkg1 = asDarcs ertes-src/testpkg1/main;
testpkg2 = asDarcs ertes-src/testpkg2/main;
};
The testpkg2 executable depends on the testpkg1 library, and it works.
The expressions are generated by cabal2nix, so no manual work is
involved. So it seems to do exactly what it should.
It's not specific to Haskell (and I haven't tried haskellng at all
yet) but for personal packages I have mypkgs/pkgname/default.nix,
and then a top-level mypkgs/default.nix:
[...]
I add that to my NIX_PATH so I can `import mypkgs` anywhere to get
nixpkgs overridden with the stuff I'm working on.
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell NG: Still no binaries
Hello everybody,
today I've attempted to switch to Haskell NG again. The new tree itself
seems to work for me, but I'm still not getting prebuilt binary
packages. The only binary I get is GHC, while every other Haskell
package seems to be compiled from source code.
I've tried with the following reasonably minimal setup. My
~/.nixpkgs/config.nix contains the following code:
nixos : {
packageOverrides = pkgs : rec {
hsEnv = pkgs.haskellngPackages.ghcWithPackages (hs: with hs; [
cabal-install
]);
};
}
In my initial attempt I would have liked to switch to the new GHC as
well, so I've also tried the following override:
hsEnv = pkgs.haskell-ng.packages.ghc7101.ghcWithPackages (hs: with hs; [
cabal-install
]);
I'm on the nixos-unstable channel:
# nix-channel --list
nixos https://nixos.org/channels/nixos-unstable
The commands I've tried to get binary packages were:
nix-env \
--option extra-binary-caches https://hydra.nixos.org \
--option extra-binary-caches https://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
nix-env \
--option extra-binary-caches http://hydra.nixos.org \
--option extra-binary-caches http://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
Neither of them gave me binaries. Am I doing something wrong there?
Background: As noted in an earlier thread my current development machine
is too weak to build everything from source. The build of the GHC
7.10-based environment above took about 30 minutes, and that doesn't
include GHC itself.
Greets,
Ertugrul
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
Hi Peter, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? Both are built from source, no binaries except GHC. You are running x86_64-linux, right? That's right. Greets, Ertugrul signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
Might it be the case that you are running nix in daemon mode and thus it ignores `binary-caches`? On Thu, Apr 16, 2015 at 7:50 PM Ertugrul Söylemez ert...@gmx.de wrote: Hi Peter, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? Both are built from source, no binaries except GHC. You are running x86_64-linux, right? That's right. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
Hi Ertugrul, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? You are running x86_64-linux, right? Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
That did it! Since I'm running NixOS I am indeed running nix-daemon. The following setting did the trick: nix.binaryCaches = [ https://cache.nixos.org/; https://hydra.nixos.org/; ]; IMHO, nix-env should pass those options on to the daemon, i.e. it should not be necessary to hard-code hydra.cryp.to as a global binary cache for this to work. Actually I'm not sure whether this is such a good idea. If it did, it would be a backdoor into fellow system users. An attacker could construct a Nix expression that matches exactly another system user's expression. Then the attacker builds it, but they tell Nix that they have a binary cache available for it, which delivers an infected version of the derivation. When the other system user tries to build the same expression, they find that it is already built, but it is actually the infected substitute injected by the attacker. Just out of curiosity, did you configure nix.trustedBinaryCaches = [ http://hydra.nixos.org http://hydra.cryp.to ]; in your configuration.nix? I didn't. Now that you mention it I briefly remember Nix telling me something about the untrusted binary cache. I just ignored it, assuming that Nix would go ahead and use it anyway. I will try with that setting. But yes, because of the above it's totally sensible that Nix doesn't just use any cache that you tell it to use. Thanks! Greets, Ertugrul signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
On Thu, Apr 16, 2015 at 11:33 PM Ertugrul Söylemez ert...@gmx.de wrote: IMHO, nix-env should pass those options on to the daemon, i.e. it should not be necessary to hard-code hydra.cryp.to as a global binary cache for this to work. Actually I'm not sure whether this is such a good idea. If it did, it would be a backdoor into fellow system users. An attacker could construct a Nix expression that matches exactly another system user's expression. Then the attacker builds it, but they tell Nix that they have a binary cache available for it, which delivers an infected version of the derivation. When the other system user tries to build the same expression, they find that it is already built, but it is actually the infected substitute injected by the attacker. And that’s exactly why Nix won’t allow an untrusted user to use a custom binary cache unless it is listed in `trusted-binary-caches` in `nix.conf`. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [haskell-ng] nix-shell mass rebuild
Hi Alan, As a non-nixos (i.e. nixpkgs only) user, which channel should I be updating from to get the up to date haskellng derivations? there are two: nix-channel --add http://hydra.nixos.org/jobset/nixpkgs/haskell-updates/channel/latest nix-channel --add http://hydra.cryp.to/jobset/nixpkgs/haskell-updates/channel/latest The latter channel is usually faster than the former, but it has binaries for x86_64-linux only. hydra.nixos.org, on the other hand, provides binaries for x86_64-darwin as well. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [haskell-ng] nix-shell mass rebuild
Thanks On Wed, Apr 1, 2015 at 1:08 PM, Peter Simons sim...@cryp.to wrote: Hi Alan, As a non-nixos (i.e. nixpkgs only) user, which channel should I be updating from to get the up to date haskellng derivations? there are two: nix-channel --add http://hydra.nixos.org/jobset/nixpkgs/haskell-updates/channel/latest nix-channel --add http://hydra.cryp.to/jobset/nixpkgs/haskell-updates/channel/latest The latter channel is usually faster than the former, but it has binaries for x86_64-linux only. hydra.nixos.org, on the other hand, provides binaries for x86_64-darwin as well. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [haskell-ng] nix-shell mass rebuild
$ nix-shell shell.nix --dry-run these derivations will be built: /nix/store/w27n1gq1hgqg60vhhbbmf8a6pkipvzyh-haskell-ansi-terminal-0.6.2.1.drv /nix/store/m27mivz3pj4rs252cmqwmirw2xkhhnqi-haskell-ansi-wl-pprint-0.6.7.1.drv /nix/store/c5hqp775nchw4kcsknpqdk4hv4f4rmqq-haskell-mtl-2.1.3.1.drv /nix/store/yp1rfjwgi7kk2255863q9lphs4km1j01-haskell-transformers-compat-0.4.0.4.drv /nix/store/3xc2cr7b4kgk4rp5l2qzrbm7b1jkzgz9-haskell-optparse-applicative-0.11.0.2.drv /nix/store/70gb4f67ys7qd65jlw0gbdy01lpvyv44-haskell-tagged-0.7.3.drv /nix/store/8yqvnzjlqch91vjhri9ilfcnn0dvfk1s-haskell-regex-base-0.93.2.drv /nix/store/2csyi16yqqvrsd9j5hj3nh0biyjyrilf-haskell-text-1.2.0.4.drv /nix/store/bxdpkji8ni5qa6n58yawqb3gg3xs230x-haskell-random-1.1.drv /nix/store/k2nndcq224vglij5rnj69wfmvy80izkj-haskell-xml-1.3.14.drv /nix/store/v12fdmaafrfjijmlxhw7idgr561m0a4d-haskell-regex-posix-0.95.2.drv /nix/store/z2an2l5vkacqw37k1i32iddqm5mrh6sq-haskell-hostname-1.0.drv /nix/store/bbdbwp1040nz4n1057khqpn6b9hbjvj3-haskell-test-framework-0.8.1.1.drv /nix/store/nlxpw9k57r3ybixxg5a7sf1c9hfgqa0m-haskell-HUnit-1.2.5.2.drv /nix/store/xrs9yj8ba2396543r5mr84j7ajzgdyfi-haskell-extensible-exceptions-0.1.1.4.drv /nix/store/7nkagk1ll0pqbxw8pqjpdd579bdd6ff8-haskell-test-framework-hunit-0.3.0.1.drv /nix/store/f08r20qrraixx1lqi51qb5n1xbj36xq4-haskell-parsec-3.1.8.drv /nix/store/7942b34ss4hcl20b5g26ihd1f2lqpjw4-haskell-regex-tdfa-rc-1.1.8.3.drv /nix/store/jkn0sy82zaaa6fgi45jq09wxaxagqfbh-haskell-stm-2.4.4.drv /nix/store/n6qvxjw84xpfiidk3wlkga2gfs5zaz1l-haskell-async-2.0.2.drv /nix/store/pkgil05jk9lkm3wpxi3wsmjk53l5h1j8-haskell-unbounded-delays-0.1.0.9.drv /nix/store/0nr5zl91smfszbrzqjfnvp8hncghkki6-haskell-tasty-0.10.1.drv /nix/store/jf5ljrzaj48khp0mnsbqb1m5czmgpl9r-haskell-primitive-0.5.4.0.drv /nix/store/rfffqv83w94xmdi7sdlnnfh7sj1q1r07-haskell-tf-random-0.5.drv /nix/store/drbgh0pyjmlmrzrx944wl6vf8hbydc2g-haskell-QuickCheck-2.7.6.drv /nix/store/kd6zcd4kg77nkknr396ji9g1bqk55lam-haskell-setenv-0.1.1.3.drv /nix/store/kigchf33vifi56kwvxpph02rjvc2k40c-haskell-quickcheck-io-0.1.1.drv /nix/store/lc2f39qq5b8cncb29fi2b3wj7mm07svq-haskell-hspec-expectations-0.6.1.1.drv /nix/store/x8kfna709vh2lbb093zzbmgbygb3wanf-haskell-hspec-meta-2.0.0.drv /nix/store/bpiag4vp9bjl8qj57was616zhcxnd6yf-haskell-hspec-discover-2.1.4.drv /nix/store/pq6i9bbzc5n45g7p985zw0hdsfpi3zlz-haskell-nanospec-0.2.0.drv /nix/store/c8lchw43r6jh7wjz36fwm3rhrypb67rh-haskell-silently-1.2.4.1.drv /nix/store/wd9ip80rnlni3320wd3zmnm7qwrzs934-haskell-hspec-core-2.1.4.drv /nix/store/zbbcimxa52cm3pxzlb780nlmrx3bdvkd-haskell-hspec-2.1.4.drv /nix/store/slrgmxpqpcs1a87l56g092qdkg5fpp5z-haskell-errorcall-eq-instance-0.1.0.drv /nix/store/0nzja1p2mgkldfnpm693mprdbwrcvnsv-haskell-base-compat-0.5.0.drv /nix/store/0r6ml2vb43gvc6p1r8ls1zn00bx9gxp5-haskell-language-haskell-extract-0.2.4.drv /nix/store/d12jpcjxg1z57ml10mdhwkmdypklfyv4-haskell-test-framework-quickcheck2-0.3.0.3.drv /nix/store/5sh2ps55x34mjn2xq2lrwqm2rz9mhgnr-haskell-syb-0.4.4.drv /nix/store/hxsg96xj68lvl15b82zxgdss071mkvlk-haskell-ChasingBottoms-1.3.0.11.drv /nix/store/jzs3mlqrav32ab1kxzmg8aipfma9in9f-haskell-hashable-1.2.3.1.drv /nix/store/3xxaa9avvvxfpz294z2m3cnfj2jhl5b6-haskell-unordered-containers-0.2.5.1.drv /nix/store/z02f66nii4m4wbvczb44bi7k6r7fa8bx-haskell-nats-1.drv /nix/store/15qdngi37l0y936kxg05dhvlal7cp1fs-haskell-semigroups-0.16.2.2.drv /nix/store/20m4k38y3zbiwm3lwgfap5d8h3xgxwl9-haskell-network-2.6.0.2.drv /nix/store/394b5diyjzbccs75kqc1lvdhskbimg9d-haskell-testpack-2.1.3.0.drv /nix/store/6hsaih5n5kf162k5xisb9hks3c8dg2v5-haskell-foreign-var-0.1.drv /nix/store/a7h1l99ssaxh0k0wv0jqxpd211glyc7f-haskell-void-0.7.drv /nix/store/jv5xy2qp7limy1a1pm9i8lv4yjzd1gl7-haskell-contravariant-1.2.2.1.drv /nix/store/hcg5c7xak4rphz9cc77czvrf3qn2rdxv-haskell-stringbuilder-0.5.0.drv /nix/store/zhyfsqpkgxbd8spf0bpzqmhd9vzdimyv-haskell-ghc-paths-0.1.0.9.drv /nix/store/x87p44pi5bkq91c3f02m6p8qidfw0pxb-haskell-doctest-0.9.13.drv /nix/store/p77xn8m8qsc1y566kdhviglrqczq1wdq-haskell-distributive-0.4.4.drv /nix/store/picv7wf4jpqxgcg9c9nnrbhflds53w2y-haskell-comonad-4.2.3.drv /nix/store/p4vbxv8x2ih3mjgwyvz3igy1i5s7y8sb-haskell-dlist-0.7.1.drv /nix/store/xh09i38gl0srw95g4cbjn9b9vivr5anz-haskell-Glob-0.7.5.drv /nix/store/6mpx6qs2cnbymdbyds6llblwmp47azcw-haskell-semigroupoids-4.3.drv /nix/store/jkl7qfri7za5r4gxk8nc5j1k1dx95b3p-haskell-profunctors-4.4.1.drv /nix/store/clzxqfwd6xgsz8l6qzcwb9k4q26zad60-haskell-bifunctors-4.2.1.drv /nix/store/fxkm2pn1f7l27ijzi3iyjchf20c3528d-haskell-prelude-extras-0.4.drv /nix/store/xpsnr27iskqfz7fqaiwklh6r7yhiymj3-haskell-free-4.11.drv /nix/store/73gim2i1wjwaj0inryrvcad4rmf4qsg6-haskell-adjunctions-4.2.drv /nix/store/7r4g1ql1nxz6zz4j4ld9n4gy7qhl56yf-haskell-tasty-hunit-0.9.1.drv /nix/store/8cja86pn889m7gqrf7fypxiz11wrqz4a-haskell-kan-extensions-4.2.1.drv
[Nix-dev] [haskell-ng] nix-shell mass rebuild
Hello, I'm using only nix pkg manager on ubuntu 14.04. Last execution of nix-shell was couple of weeks ago. After channel update (nix-channel --update) on today, I only updated 'nix' pkg manager manually because nix tried to update cabal2nix 2.x - 1.7.x . Then tried nix-shell on my project directory and got so many drv rebuild. $ nix-shell shell.nix --dry-run these derivations will be built: /nix/store/w27n1gq1hgqg60vhhbbmf8a6pkipvzyh-haskell-ansi-terminal-0.6.2.1.drv /nix/store/m27mivz3pj4rs252cmqwmirw2xkhhnqi-haskell-ansi-wl-pprint-0.6.7.1.drv /nix/store/c5hqp775nchw4kcsknpqdk4hv4f4rmqq-haskell-mtl-2.1.3.1.drv /nix/store/yp1rfjwgi7kk2255863q9lphs4km1j01-haskell-transformers-compat-0.4.0.4.drv /nix/store/3xc2cr7b4kgk4rp5l2qzrbm7b1jkzgz9-haskell-optparse-applicative-0.11.0.2.drv /nix/store/70gb4f67ys7qd65jlw0gbdy01lpvyv44-haskell-tagged-0.7.3.drv /nix/store/8yqvnzjlqch91vjhri9ilfcnn0dvfk1s-haskell-regex-base-0.93.2.drv /nix/store/2csyi16yqqvrsd9j5hj3nh0biyjyrilf-haskell-text-1.2.0.4.drv /nix/store/bxdpkji8ni5qa6n58yawqb3gg3xs230x-haskell-random-1.1.drv /nix/store/k2nndcq224vglij5rnj69wfmvy80izkj-haskell-xml-1.3.14.drv /nix/store/v12fdmaafrfjijmlxhw7idgr561m0a4d-haskell-regex-posix-0.95.2.drv /nix/store/z2an2l5vkacqw37k1i32iddqm5mrh6sq-haskell-hostname-1.0.drv /nix/store/bbdbwp1040nz4n1057khqpn6b9hbjvj3-haskell-test-framework-0.8.1.1.drv /nix/store/nlxpw9k57r3ybixxg5a7sf1c9hfgqa0m-haskell-HUnit-1.2.5.2.drv /nix/store/xrs9yj8ba2396543r5mr84j7ajzgdyfi-haskell-extensible-exceptions-0.1.1.4.drv /nix/store/7nkagk1ll0pqbxw8pqjpdd579bdd6ff8-haskell-test-framework-hunit-0.3.0.1.drv /nix/store/f08r20qrraixx1lqi51qb5n1xbj36xq4-haskell-parsec-3.1.8.drv /nix/store/7942b34ss4hcl20b5g26ihd1f2lqpjw4-haskell-regex-tdfa-rc-1.1.8.3.drv /nix/store/jkn0sy82zaaa6fgi45jq09wxaxagqfbh-haskell-stm-2.4.4.drv /nix/store/n6qvxjw84xpfiidk3wlkga2gfs5zaz1l-haskell-async-2.0.2.drv /nix/store/pkgil05jk9lkm3wpxi3wsmjk53l5h1j8-haskell-unbounded-delays-0.1.0.9.drv /nix/store/0nr5zl91smfszbrzqjfnvp8hncghkki6-haskell-tasty-0.10.1.drv /nix/store/jf5ljrzaj48khp0mnsbqb1m5czmgpl9r-haskell-primitive-0.5.4.0.drv /nix/store/rfffqv83w94xmdi7sdlnnfh7sj1q1r07-haskell-tf-random-0.5.drv /nix/store/drbgh0pyjmlmrzrx944wl6vf8hbydc2g-haskell-QuickCheck-2.7.6.drv /nix/store/kd6zcd4kg77nkknr396ji9g1bqk55lam-haskell-setenv-0.1.1.3.drv /nix/store/kigchf33vifi56kwvxpph02rjvc2k40c-haskell-quickcheck-io-0.1.1.drv /nix/store/lc2f39qq5b8cncb29fi2b3wj7mm07svq-haskell-hspec-expectations-0.6.1.1.drv /nix/store/x8kfna709vh2lbb093zzbmgbygb3wanf-haskell-hspec-meta-2.0.0.drv /nix/store/bpiag4vp9bjl8qj57was616zhcxnd6yf-haskell-hspec-discover-2.1.4.drv /nix/store/pq6i9bbzc5n45g7p985zw0hdsfpi3zlz-haskell-nanospec-0.2.0.drv /nix/store/c8lchw43r6jh7wjz36fwm3rhrypb67rh-haskell-silently-1.2.4.1.drv /nix/store/wd9ip80rnlni3320wd3zmnm7qwrzs934-haskell-hspec-core-2.1.4.drv /nix/store/zbbcimxa52cm3pxzlb780nlmrx3bdvkd-haskell-hspec-2.1.4.drv /nix/store/slrgmxpqpcs1a87l56g092qdkg5fpp5z-haskell-errorcall-eq-instance-0.1.0.drv /nix/store/0nzja1p2mgkldfnpm693mprdbwrcvnsv-haskell-base-compat-0.5.0.drv /nix/store/0r6ml2vb43gvc6p1r8ls1zn00bx9gxp5-haskell-language-haskell-extract-0.2.4.drv /nix/store/d12jpcjxg1z57ml10mdhwkmdypklfyv4-haskell-test-framework-quickcheck2-0.3.0.3.drv /nix/store/5sh2ps55x34mjn2xq2lrwqm2rz9mhgnr-haskell-syb-0.4.4.drv /nix/store/hxsg96xj68lvl15b82zxgdss071mkvlk-haskell-ChasingBottoms-1.3.0.11.drv /nix/store/jzs3mlqrav32ab1kxzmg8aipfma9in9f-haskell-hashable-1.2.3.1.drv /nix/store/3xxaa9avvvxfpz294z2m3cnfj2jhl5b6-haskell-unordered-containers-0.2.5.1.drv /nix/store/z02f66nii4m4wbvczb44bi7k6r7fa8bx-haskell-nats-1.drv /nix/store/15qdngi37l0y936kxg05dhvlal7cp1fs-haskell-semigroups-0.16.2.2.drv /nix/store/20m4k38y3zbiwm3lwgfap5d8h3xgxwl9-haskell-network-2.6.0.2.drv /nix/store/394b5diyjzbccs75kqc1lvdhskbimg9d-haskell-testpack-2.1.3.0.drv /nix/store/6hsaih5n5kf162k5xisb9hks3c8dg2v5-haskell-foreign-var-0.1.drv /nix/store/a7h1l99ssaxh0k0wv0jqxpd211glyc7f-haskell-void-0.7.drv /nix/store/jv5xy2qp7limy1a1pm9i8lv4yjzd1gl7-haskell-contravariant-1.2.2.1.drv /nix/store/hcg5c7xak4rphz9cc77czvrf3qn2rdxv-haskell-stringbuilder-0.5.0.drv /nix/store/zhyfsqpkgxbd8spf0bpzqmhd9vzdimyv-haskell-ghc-paths-0.1.0.9.drv /nix/store/x87p44pi5bkq91c3f02m6p8qidfw0pxb-haskell-doctest-0.9.13.drv /nix/store/p77xn8m8qsc1y566kdhviglrqczq1wdq-haskell-distributive-0.4.4.drv /nix/store/picv7wf4jpqxgcg9c9nnrbhflds53w2y-haskell-comonad-4.2.3.drv /nix/store/p4vbxv8x2ih3mjgwyvz3igy1i5s7y8sb-haskell-dlist-0.7.1.drv /nix/store/xh09i38gl0srw95g4cbjn9b9vivr5anz-haskell-Glob-0.7.5.drv /nix/store/6mpx6qs2cnbymdbyds6llblwmp47azcw-haskell-semigroupoids-4.3.drv /nix/store/jkl7qfri7za5r4gxk8nc5j1k1dx95b3p-haskell-profunctors-4.4.1.drv /nix/store/clzxqfwd6xgsz8l6qzcwb9k4q26zad60-haskell-bifunctors-4.2.1.drv /nix/store/fxkm2pn1f7l27ijzi3iyjchf20c3528d-haskell-prelude-extras-0.4.drv /nix/store/xpsnr27iskqfz7fqaiwklh6r7yhiymj3-haskell-free-4.11.drv /nix/store/73gim2i1wjwaj0inryrvcad4rmf4qsg6-haskell-adjunctions-4.2.drv
Re: [Nix-dev] [haskell-ng] nix-shell mass rebuild
YCH dontdie...@gmail.com writes: $ cat /etc/nix/nix.conf extra-binary-caches = http://hydra.nixos.org http://hydra.cryp.to Why updates are not in binary-caches? Both of these servers compile Haskell packages relative to the 'master' branch of Nixpkgs. The 'nixos-unstable' channel has been lagging behind 'master' for a while now. My guess is that these packages you'd like to retrieve have been garbage collected a while ago and are no longer available. Generally speaking, it feels a little extreme to call a rebuild of 80 packages a mass rebuild. I don't know what kind of hardware you're working on, but a modern machine should easily compile those packages within a couple of minutes. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell NG: multiple project usage
I added a new datatype to tasty-core, which I'd like to use in tasty-quickcheck. I generated two default.nix files as described here: http://stackoverflow.com/questions/27968909/how-to-get-cabal-and-nix-work-together And put this shell.nix file into the tasty-quickcheck directory: https://gist.github.com/nkaretnikov/ec2c1765b37b8db2324d After running nix-shell -I ~ --pure and cabal build in the same directory, tasty-quickcheck still can't find my datatype. What's wrong? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell NG: let's update the wiki
The current Haskell package set will be removed in a few weeks: https://github.com/NixOS/nixpkgs/pull/6670#issuecomment-77688859 So it'd be nice to prepare the wiki. I've added a new section and a useful snippet: https://nixos.org/wiki/Haskell#Haskell_NG I cannot just paste the other code I've found due to copyright-related issues, so it needs to be done by the authors. Please help! signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng: shell.nix magic to infer .env?
I now understand why we don't neccesarily want to use the with-packages wrapper for building (Peter wrote a nice detailed response to the PR, if anyone is interested in the reasons). I am now wondering, why don't we make the `.env` shellHook the default shellHook for the derivation too? I guess this can make debugging for people working on the generic-builder more difficult, since they can no longer use nix-shell for that. However, I think this is not the common usecase, which is in my opinion that you just want a shell to develop in. There is another neat trick I learned from Oliver Charles is to use nix-shell (with .env) only for `cabal configure`. The `cabal build` command then works fine outside the shell too, since cabal caches the path to GHC in dist/setup-config. If you use this, you don't need to use nix-shell very often at all. Regards, Benno (previously, I forgot to send this to nix-dev too) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng: shell.nix magic to infer .env?
Hi Benno, Why don't we make the `.env` shellHook the default shellHook for the derivation too? Mateusz requested something like that earlier, and I created [1] to make sure it's not forgotten. Basically, the idea was that an appropriate shellHook allows you to work interactively in the standard build, too. All you need is a couple of aliases and/or variables that provide convenient short-cuts for building ./Setup and for running ./Setup configure with appropriate flags. I believe the original mailing list thread about this subject began at [2]. I guess this can make debugging for people working on the generic-builder more difficult, since they can no longer use nix-shell for that. I wouldn't worry about that. If this ever becomes a problem, then we'll extend nix-shell with a flag that tells it to ignore shellHook. :-) Take care, Peter [1] https://github.com/NixOS/nixpkgs/issues/5916 [2] http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015790.html ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng: shell.nix magic to infer .env?
Hi Mateusz,
With old Haskell setup we'd essentially have a shell.nix that was a bit like
let
pkgs = import nixpkgs {}
some_stuff = …;
in some_stuff.callPackage ./. {};
or some variation thereof. This allowed us to both nix-shell *and*
nix-build shell.nix out of the box. But with haskell-ng we end up with
(some_stuff.callPackage ./. {}).env;
which is all fine and dandy for when we want a shell but nix-build no
longer Just Works™.
just omit the .env part from the expression above. Then running
$ nix-build shell.nix
will build the package, and
$ nix-shell -A env
will give you an interactive environment.
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell-ng: shell.nix magic to infer .env?
Hi Mateusz, Is there any way to recover old behaviour? I imagine if we can tell if we're entering a nix-shell or not then we can switch inside the expr and use .env when appropriate but I don't know how to achieve this. I have this PR: https://github.com/NixOS/nixpkgs/pull/6307 which would solve this issue. A simpler fix would be to just use that mechanism for building the wrapper for the shellHook, not changing the rest of the builder. But that is IMO the worst of both, since then we'd need to rebuild haskell packages if the wrapper changes while still not using the wrapper for the real build. Regards, Benno ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [haskell NG] Override package
Hello,
I've done successfully using method 1) .
Thanks.
~~~
~/hdevtools $ cabal2nix . default.nix
~/ $ cat ~/.nixpkgs/config.nix
{
allowUnfree = true;
haskellPackageOverrides = self: super: {
hdevtools = self.callPackage ../hdevtools {};
};
}
~/cis194 $ cat shell.nix
with (import nixpkgs {}).pkgs;
let pkg = haskellngPackages.callPackage
({ mkDerivation, base, MissingH, QuickCheck, stdenv, tasty
, tasty-hunit, tasty-quickcheck, tasty-rerun, tasty-th
}:
mkDerivation {
pname = cis194;
version = 0.1.0.0;
src = ./.;
isLibrary = false;
isExecutable = true;
buildDepends = [
base MissingH QuickCheck tasty tasty-hunit tasty-quickcheck
tasty-rerun tasty-th
];
buildTools = [
haskellngPackages.hdevtools
haskellngPackages.cabal-install
];
license = stdenv.lib.licenses.unfree;
}) {};
in
pkg.env
~~~
On Wed, Feb 18, 2015 at 8:18 AM, Daniel Bergey ber...@teallabs.org wrote:
On 2015-02-16 at 08:42, YCH dontdie...@gmail.com wrote:
I've read quite many document. Wiki, nix pills, ... . But I'm confused about
so many different ways doing similar things. And I'm worried about haskell-ng
specific things. There is already 'haskellngPackages.hdevtools'. So I should
override using ~/hdevtools. I'll attach my current setup information.
Nix certainly has an overwhelming number of options for similar things.
Here are two options for your situation:
1. Override hdevtools for all your builds, editing
~/.nixpkgs/config.nix, following the explanation in [1]. This is
probably the right thing; I expect you always want the patched
hdevtools. A complete config.nix:
2. Override hdevtools in your shell.nix, just for this build. This is
useful when you need a patched version of some Haskell library, rather
than a build tool. In this case, add to the let definitions (before
pkg)
hdevtools = haskellngPackages.callPackage ~/hdevtools {};
I think you'll need to replace the ~ with your homedir; ISTR Nix doesn't
interpret ~. Then change your buildTools line to refer to hdevtools,
not haskellngPackages.hdevtools.
cheers,
bergey
Footnotes:
[1] http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015601.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [haskell NG] Override package
Hello,
I'm very happily learning Haskell with nix-shell and haskell-ng environment. In
comparison to previous 'haskell', there is no problem at all.
But I've found problem that hdevtools does not see related build-depends
options in cabal file.
https://github.com/bitc/hdevtools/issues/38
So I would try patched hdevtools from fork.
https://github.com/maximkulkin/hdevtools
Cloned, checked out proper branch. What is next step?
I've read quite many document. Wiki, nix pills, ... . But I'm confused about
so many different ways doing similar things. And I'm worried about haskell-ng
specific things. There is already 'haskellngPackages.hdevtools'. So I should
override using ~/hdevtools. I'll attach my current setup information.
Arch Linux
nix-unstable
Thanks.
~~~
$ nix-env -q
cabal-install-1.22.0.0
cabal2nix-2.0
nix-1.8
nox-0.0.1
$ ls -1
cis194.cabal
HW01.hs
HW02.hs
LICENSE
Main.hs
Setup.hs
shell.nix
Test.hs
... snip ...
$ cat cis194.cabal
-- Initial cis194.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name:cis194
version: 0.1.0.0
-- synopsis:
-- description:
-- license:
license-file:LICENSE
author: dontdieych
maintainer: dontdie...@gmail.com
-- copyright:
-- category:
build-type: Simple
-- extra-source-files:
cabal-version: =1.10
library
default-language:Haskell2010
build-depends:
base =4.7 4.8
, MissingH
exposed-modules:
HW01
, HW02
executable cis194
default-language:Haskell2010
main-is: Main.hs
-- hs-source-dirs:
-- other-modules:
-- other-extensions:
build-depends:
base =4.7 4.8
test-suite test
default-language: Haskell2010
type: exitcode-stdio-1.0
main-is: Test.hs
build-depends:
base =4.7 4.8
, tasty
, tasty-th
, tasty-quickcheck
, tasty-rerun
-- , QuickCheck
$ cat shell.nix # cabal2nix . --shell shell.nix
with (import nixpkgs {}).pkgs;
let pkg = haskellngPackages.callPackage
({ mkDerivation, base, MissingH, QuickCheck, stdenv, tasty
, tasty-hunit, tasty-quickcheck, tasty-rerun, tasty-th
}:
mkDerivation {
pname = cis194;
version = 0.1.0.0;
src = ./.;
isLibrary = false;
isExecutable = true;
buildDepends = [
base MissingH QuickCheck tasty tasty-hunit tasty-quickcheck
tasty-rerun tasty-th
];
buildTools = [
haskellngPackages.hdevtools # I've added this config.
];
license = stdenv.lib.licenses.unfree;
}) {};
in
pkg.env
$ cat ../hdevtools/default.nix # via cabal2nix . defult.nix
{ mkDerivation, base, Cabal, cmdargs, directory, filepath, ghc
, ghc-paths, network, stdenv, syb, time, transformers, unix
}:
mkDerivation {
pname = hdevtools;
version = 0.1.0.6;
src = ./.;
isLibrary = false;
isExecutable = true;
buildDepends = [
base Cabal cmdargs directory filepath ghc ghc-paths network syb
time transformers unix
];
homepage = https://github.com/bitc/hdevtools/;;
description = Persistent GHC powered background server for FAST
haskell development tools;
license = stdenv.lib.licenses.mit;
}
~~~
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Peter Simons sim...@cryp.to writes: We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? It does to me. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/23/2015 07:57 AM, Peter Simons wrote: Hi Mateusz, Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. I'm not sure what you mean. The number of files that you have to change to accomplish non-standard behavior should not be different from what it fwas before, i.e. the use of nix-shell certainly shouldn't have gotten more complicated than it was. Could you please elaborate a little how you've used nix-shell before and why that particular use-case won't now work anymore? Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Previously, you generated a default.nix file with cabal2nix and ran that from a hand-written shell.nix file. Why do you think that this use-case is no longer possible? What exactly do you mean by re-generating both files? I merely meant that a ‘simple’ callPackage did not work (dependency problems) but Richard Wallace set it straight for me now: adding .env pretty much let's me use my old setup. So that part is solved. Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. It never occurred to me to configure interactive builds with the same flags Nixpkgs uses, because the default builder sets options that I wouldn't want (--prefix=$out) while leaving out flags that I would want (--ghc-option=-j). If you think this is important, then we can define a shell variable in the interactive environment, say $configureFlags, that you can pass to ./Setup or cabal during the configure phase. Would you like that? That sounds useful. Note that you can always use the old-style nix-shell approach and run the default builder, i.e.: $ cabal get haddock $ cd haddock-2.15.0.2 $ nix-shell --pure ~/.nix-defexpr -A haskellngPackages.haddock $ runHook setupCompilerEnvironmentPhase runHook jailbreakPhase runHook compileBuildDriverPhase $ eval $configurePhase eval $buildPhase eval $checkPhase We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? This also sounds useful. I think this solves all my ‘problems’ for now. Thank you for all your work! I hope this helps, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/22/2015 05:52 PM, Mateusz Kowalczyk wrote:
Hi,
Before haskell-ng my workflow to check that everything is OK in a
package was to nix-shell and run the above commands. I could also
rebuild and run tests again that way but apparently that no longer
works: even Setup file is no longer compiled. ‘genericBuild’ only works
for installations which is not what I'm after.
What's the new in-shell workflow?
It was suggested that I should ghc --make Setup and Setup
configure/build/test but for expression given at the bottom, it fails:
[nix-shell:~/programming/haddock]$ ./Setup configure
Configuring haddock-2.16.0...
Setup: At least the following dependencies are missing:
haddock-api ==2.16.0
but nix-building the package works fine.
Expr:
[nix-shell:~/programming/haddock]$ cat default.nix
{ mkDerivation, base, Cabal, directory, filepath, haddock-api
, process, stdenv
}:
mkDerivation {
pname = haddock;
version = 2.16.0;
src = /home/shana/programming/haddock;
isLibrary = false;
isExecutable = true;
buildDepends = [ base haddock-api ];
testDepends = [ base Cabal directory filepath process ];
preCheck = unset GHC_PACKAGE_PATH;
homepage = http://www.haskell.org/haddock/;;
description = A documentation-generation tool for Haskell libraries;
license = stdenv.lib.licenses.bsd3;
maintainers = with stdenv.lib.maintainers; [ fuuzetsu ];
}
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Hi Mateusz, What's the new in-shell workflow? Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Hi Mateusz,
You don't have to use cabal2nix to generate the default.nix and shell.nix
files. It would be enough to generate the default.nix file and then in
shell.nix you can have
with (import nixpkgs {}).pkgs;
(haskellngPackages.callPackage ./. {}).env
To add overrides, you would do something similar to
with (import nixpkgs {}).pkgs;
with (import nixpkgs/pkgs/development/haskell-modules/lib.nix {
inherit pkgs; });
let modifiedHaskellPackages = haskellngPackages.override {
overrides = self: super: {
http-media = dontCheck super.http-media;
Cabal = super.Cabal_1_20_0_3;
webcrank = self.callPackage ./. {};
};
};
in modifiedHaskellPackages.webcrank.env
For my own development I've gone a step further, I generate the default.nix
file with cabal2nix. Then I create a project-name.nix (in this case
webcrank.nix) much like the above
with (import nixpkgs {}).pkgs;
with (import nixpkgs/pkgs/development/haskell-modules/lib.nix {
inherit pkgs; });
let modifiedHaskellPackages = haskellngPackages.override {
overrides = self: super: {
http-media = dontCheck super.http-media;
Cabal = super.Cabal_1_20_0_3;
webcrank = self.callPackage ./. {};
};
};
in modifiedHaskellPackages.webcrank
Notice that .env was removed from the end. This file I use with
nix-build and then nix-copy-closure to do deployments. In my shell.nix I
add some addition things, like dev tools
with (import nixpkgs {}).pkgs;
with (import nixpkgs/pkgs/development/haskell-modules/lib.nix {
inherit pkgs; });
(overrideCabal (import ./webcrank.nix) (drv: {
buildTools = [
haskellngPackages.ghc-mod
];
})).env
This setup has been working well for me so far, hopefully it will help you
too.
Rich
On Thu, Jan 22, 2015 at 5:24 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 01/22/2015 09:54 PM, Peter Simons wrote:
Hi Mateusz,
What's the new in-shell workflow?
Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524
help?
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Yes though it seems that we now need to update two files when making any
changes: default.nix so that we can callPackage it in overrides and such
(for example if it's a private package) and shell.nix so that we can
enter sane environment.
Previously we could simply cabal2nix into default.nix and from shell.nix
callPackage ./. in simple case or add any extra shell-only settings in
there. Now it seems that if I add a dependency I need to regenerate both
files which is not fun if we have written any customisation. Am I wrong?
Nevetheless, I got on fine once I figured out I need a fancier shell.nix
such as one cabal2nix gave me. Another downside is that manual use of
Setup won't inherit flags specified in the expression: we manually have
to --enable-testsuite whereas eval $configurePhase would do that for
use when doCheck = true;. So overall it seems to me that there is a bit
more manual work involved though things seem nicer in general so far.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/22/2015 09:54 PM, Peter Simons wrote: Hi Mateusz, What's the new in-shell workflow? Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Nevetheless, I got on fine once I figured out I need a fancier shell.nix such as one cabal2nix gave me. Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. So overall it seems to me that there is a bit more manual work involved though things seem nicer in general so far. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Hi, Before haskell-ng my workflow to check that everything is OK in a package was to nix-shell and run the above commands. I could also rebuild and run tests again that way but apparently that no longer works: even Setup file is no longer compiled. ‘genericBuild’ only works for installations which is not what I'm after. What's the new in-shell workflow? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Hi Mateusz, Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. I'm not sure what you mean. The number of files that you have to change to accomplish non-standard behavior should not be different from what it fwas before, i.e. the use of nix-shell certainly shouldn't have gotten more complicated than it was. Could you please elaborate a little how you've used nix-shell before and why that particular use-case won't now work anymore? Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Previously, you generated a default.nix file with cabal2nix and ran that from a hand-written shell.nix file. Why do you think that this use-case is no longer possible? What exactly do you mean by re-generating both files? Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. It never occurred to me to configure interactive builds with the same flags Nixpkgs uses, because the default builder sets options that I wouldn't want (--prefix=$out) while leaving out flags that I would want (--ghc-option=-j). If you think this is important, then we can define a shell variable in the interactive environment, say $configureFlags, that you can pass to ./Setup or cabal during the configure phase. Would you like that? Note that you can always use the old-style nix-shell approach and run the default builder, i.e.: $ cabal get haddock $ cd haddock-2.15.0.2 $ nix-shell --pure ~/.nix-defexpr -A haskellngPackages.haddock $ runHook setupCompilerEnvironmentPhase runHook jailbreakPhase runHook compileBuildDriverPhase $ eval $configurePhase eval $buildPhase eval $checkPhase We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? I hope this helps, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Hi Russel, So please keep an eye out for long evaluation times when using deepOverride as you continue your work. :) you were right. deepOverride is too slow to be feasible for anything but trivial cases. The haskell-ng package set still support deepOverride, but the recommended way to accomplish deep overrides is overrideScope https://github.com/NixOS/nixpkgs/commit/3c8b33eee442fd573d47555122cfe358134aeb64 which is, of course, exactly the solution you proposed in the 'haskellPackagesFixpoint' branch. Great job! Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Hi Charles, How much work remains before we can flip the switch? the 'haskell-ng' branch in [1] is pretty stable by now. According to [2], we can build approximately 50% of Hackage. There's more work to be done in cabal2nix, improving the generated package list to get that percentage up some more, but IMHO the major challenges have been solved. Anyone who wants to look at the code, can check out [3]. Also, everyone is welcome to try out the new Haskell environment: get the 'haskell-ng' branch, add the attribute provideOldHaskellAttributeNames = true; to your ~/.nixpkgs/config.nix file, and then your normal configuration should work just like it did before -- unless, if your configuration was based on the ghc-wrapper. Then you'll have to convert to ghcWithPackages, because the wrapper is gone. It will be 2-3 more weeks until I'll open a PR, asking for review before merging to 'master'. Best regards, Peter [1] https://github.com/peti/nixpkgs [2] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates [3] https://github.com/peti/nixpkgs/blob/haskell-ng/pkgs/development/haskell-modules ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Wow, very exciting! Hopefully we can get GHCJS ready as a first-class citizen by then. Cheers! -Charles On Tue, Dec 30, 2014 at 4:58 AM, Peter Simons sim...@cryp.to wrote: Hi Charles, How much work remains before we can flip the switch? the 'haskell-ng' branch in [1] is pretty stable by now. According to [2], we can build approximately 50% of Hackage. There's more work to be done in cabal2nix, improving the generated package list to get that percentage up some more, but IMHO the major challenges have been solved. Anyone who wants to look at the code, can check out [3]. Also, everyone is welcome to try out the new Haskell environment: get the 'haskell-ng' branch, add the attribute provideOldHaskellAttributeNames = true; to your ~/.nixpkgs/config.nix file, and then your normal configuration should work just like it did before -- unless, if your configuration was based on the ghc-wrapper. Then you'll have to convert to ghcWithPackages, because the wrapper is gone. It will be 2-3 more weeks until I'll open a PR, asking for review before merging to 'master'. Best regards, Peter [1] https://github.com/peti/nixpkgs [2] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates [3] https://github.com/peti/nixpkgs/blob/haskell-ng/pkgs/development/haskell-modules ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
On Sun, 28 Dec 2014, Charles Strahan wrote: I'm trying to think of a way of selling my oop library [...] What OOP library are you talking about? Is it available for me to view online? Sure, you can look at lib/oop.nix from https://github.com/NixOS/nixpkgs/commit/6daa5a15a71021e6c1e77fec098eba818755e5aa See also http://r6.ca/blog/20140422T142911Z.html Package collections is the first time I have really felt that OOP was the best solution to the problem at hand, though I kind of think the collection of versioned packages should be separate from the recursive knot of curated packages for installation. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
I'm trying to think of a way of selling my oop library [...] What OOP library are you talking about? Is it available for me to view online? -Charles On Thu, Dec 18, 2014 at 12:38 PM, rocon...@theorem.ca wrote: On Thu, 18 Dec 2014, Peter Simons wrote: Hi Russel, 2) Haskell packages support 'deepOverride'. How would you feel about using my overrideScope functionality from my haskellPackagesFixpoint branch instead? the first version of my re-factored Haskell code defined deep overrides exactly the way you did it. Check out the definePackage function in [1]. You'll find that I studied your work thoroughly. My impressions are: 1. overrideScope and deepOverride achieve the same goal. I discovered no case where one function worked but the other one didn't. 2. deepOverride is a standard function every callPackage derivation supports. overrideScope, on the other hand, is not. 3. deepOverride is implemented in a simple generic algorithm (for appropriate definitions of the term simple) that requires no special support from the haskellPackages record to function. overrideScope, on the other hand, needs the magic nixClass attribute (__unfix__ in my code) to build a stack of extension functions. Ultimately, I felt that I should stick to the standard deepOverride mechanism mostly due to Occam's razor'ish reasoning: I'd rather not introduce a new sophisticated tying-the-knot mechanism to haskellPackages just to do the same thing that deepOverride can do already. Does that make sense? That is fair reasoning. I will add that I expect overrideScope to run exponentially faster than deepOverride in worst case. A similar change to replace-dependency took the evaluation time for replacing bash in a NixOS system from 65 minutes to instantaneous https://githum.com/NixOS/nixpkgs/pull/4313. Replacing bash in a NixOS system is probably *the* worst case scenario because bash so deep in the dependency graph. Until deepOverride starts taking appreciable time, the efficencies of overrideScope is probably not yet a pursuasive argument. So please keep an eye out for long evaluation times when using deepOverride as you continue your work. :) Haskell applications have deeper and more fine grained dependencies than regular applications so you might be more likely to run into evaluation time problems than others. What I really need to do is convince Eelco Dolstra and Michael Raskin that semantics of overriding packages and semantics of object oriented programmed coincide and they should adopt my oop library for implementing the overriding mechanism. I'm trying to think of a way of selling my oop library to them that is a little more light weight that flying to europe to give them a presenation. Maybe I should use the Ocaml package set as a testbed to demonstrate overrideScope. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Hi Russel, 2) Haskell packages support 'deepOverride'. How would you feel about using my overrideScope functionality from my haskellPackagesFixpoint branch instead? the first version of my re-factored Haskell code defined deep overrides exactly the way you did it. Check out the definePackage function in [1]. You'll find that I studied your work thoroughly. My impressions are: 1. overrideScope and deepOverride achieve the same goal. I discovered no case where one function worked but the other one didn't. 2. deepOverride is a standard function every callPackage derivation supports. overrideScope, on the other hand, is not. 3. deepOverride is implemented in a simple generic algorithm (for appropriate definitions of the term simple) that requires no special support from the haskellPackages record to function. overrideScope, on the other hand, needs the magic nixClass attribute (__unfix__ in my code) to build a stack of extension functions. Ultimately, I felt that I should stick to the standard deepOverride mechanism mostly due to Occam's razor'ish reasoning: I'd rather not introduce a new sophisticated tying-the-knot mechanism to haskellPackages just to do the same thing that deepOverride can do already. Does that make sense? Best regards, Peter [1] https://github.com/NixOS/cabal2nix/blob/070a5342a9dd5bbb6387f16750941881889c4cc8/doc/ng.nix ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
On Thu, 18 Dec 2014, Peter Simons wrote: Hi Russel, 2) Haskell packages support 'deepOverride'. How would you feel about using my overrideScope functionality from my haskellPackagesFixpoint branch instead? the first version of my re-factored Haskell code defined deep overrides exactly the way you did it. Check out the definePackage function in [1]. You'll find that I studied your work thoroughly. My impressions are: 1. overrideScope and deepOverride achieve the same goal. I discovered no case where one function worked but the other one didn't. 2. deepOverride is a standard function every callPackage derivation supports. overrideScope, on the other hand, is not. 3. deepOverride is implemented in a simple generic algorithm (for appropriate definitions of the term simple) that requires no special support from the haskellPackages record to function. overrideScope, on the other hand, needs the magic nixClass attribute (__unfix__ in my code) to build a stack of extension functions. Ultimately, I felt that I should stick to the standard deepOverride mechanism mostly due to Occam's razor'ish reasoning: I'd rather not introduce a new sophisticated tying-the-knot mechanism to haskellPackages just to do the same thing that deepOverride can do already. Does that make sense? That is fair reasoning. I will add that I expect overrideScope to run exponentially faster than deepOverride in worst case. A similar change to replace-dependency took the evaluation time for replacing bash in a NixOS system from 65 minutes to instantaneous https://githum.com/NixOS/nixpkgs/pull/4313. Replacing bash in a NixOS system is probably *the* worst case scenario because bash so deep in the dependency graph. Until deepOverride starts taking appreciable time, the efficencies of overrideScope is probably not yet a pursuasive argument. So please keep an eye out for long evaluation times when using deepOverride as you continue your work. :) Haskell applications have deeper and more fine grained dependencies than regular applications so you might be more likely to run into evaluation time problems than others. What I really need to do is convince Eelco Dolstra and Michael Raskin that semantics of overriding packages and semantics of object oriented programmed coincide and they should adopt my oop library for implementing the overriding mechanism. I'm trying to think of a way of selling my oop library to them that is a little more light weight that flying to europe to give them a presenation. Maybe I should use the Ocaml package set as a testbed to demonstrate overrideScope. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Hi Shea, Can we take this opportunity to dashify attribute names as well? it's already done. :-) All attributes in [1] match the name of the package. The file [2] implements an (optional) compatibility layer to provide the old camel-case style names for a grace period. Best regards, Peter [1] https://raw.githubusercontent.com/peti/nixpkgs/haskell-ng/pkgs/development/haskell-modules/hackage-packages.nix [2] https://raw.githubusercontent.com/peti/nixpkgs/haskell-ng/pkgs/development/haskell-modules/compat-layer.nix ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Nice! Then this branch has my full support ;) On Dec 14, 2014, at 6:40 PM, Peter Simons sim...@cryp.to wrote: Hi Shea, Can we take this opportunity to dashify attribute names as well? it's already done. :-) All attributes in [1] match the name of the package. The file [2] implements an (optional) compatibility layer to provide the old camel-case style names for a grace period. Best regards, Peter [1] https://raw.githubusercontent.com/peti/nixpkgs/haskell-ng/pkgs/development/haskell-modules/hackage-packages.nix [2] https://raw.githubusercontent.com/peti/nixpkgs/haskell-ng/pkgs/development/haskell-modules/compat-layer.nix ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
On Dec 12, 2014, at 11:19 PM, Marc Weber marco-owe...@gmx.de wrote:
- hackage-packages.nix is generated automatically by the hackage2nix
utility
from the v2.x branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary.
So does the spirit behind hack-nix win finally? Finally? :)
I don’t think Peter intends to generate the package set at evaluation time, a
static file will be committed.
If we rewrite the stuff we should get it right this time.
I feel getting this right means
1) versioning hackage
2) implement a way to retrieve hackage packages (either by api or from
versioned hackage dump)
3) share package resolution with cabal (don't invent our own stuff -
because it will always be a lot of work and be totally different)
AFAIK Shea has added a way to load .dll functions. I think I remember it
is possible to call Haskell from C code. Thus what about collaborating
on the implementation sketched above?
I don’t think builtins.importNative or nix-exec should be used as part of
nixpkgs. Installing a package should not be able to execute arbitrary code as
your user.
It would serve as sample which could be adopted for the other
universes (perl/python/ruby/java/scala/rust/vim/emacs/whatever).
Thus how could usage look like?
haskellPackages {
hackage-dbs: [
http://some-mirror/version/2014-12-10-hackage-packages.tar.gz;)
my custom stuff
]
resolve: bytestring
}
Due to referencing a hackage like database by date it should be
deterministic.
Fetching all versions of a package could be done by API (HTTP) or such -
thus downloading hackage would no longer be necessary.
Thoughts?
This is the next thing I'd try trying to learn from hack-nix.
For all of you who don't know what hack-nix is: Its a brute for
dependency solver written in Nix reading a hackage database which was
serialized to a .nix file doing exactly what Peter wants to implement:
Latest versions + some manually added older versions to make packages
resolve. Additionally its easy to add your own packages (eg dev
versions) and call the solver as well as patch packages (eg .cabal
files, especially its dependency information) before turning it into a
huge .nix file.
You can find a short description
https://nixos.org/wiki/Nixpkgs-haskell-overlay
It was meant to be a proof of concept. Now I'd like to ask you whether
you would prefer joining a common effort which is most likely to work.
Its too painful to role my own solutions for everything (haskell, ruby
overlay etc - even though it often works nicely - and fails due to lack
of man power).
Peter: Please comment on the proposal, I'd rather join than keeping my
own stuff, but your attempt just seems to be another hack-nix with all
of its problems.
Who would join implementing the design I've sketched above?
Live is too short IMHO. My point of view might be limited - thus if I
make any bad assumptions please tell me.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
On Fri, 12 Dec 2014, Peter Simons wrote:
Hi Peter,
2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
non-default version of 'binary'. Then
foo.deepOverride { binary = self.binary_0_4_0_1; };
gives a derivation that uses this particular version to build 'foo' as well
as all of foo's build inputs.
How would you feel about using my overrideScope functionality from my
haskellPackagesFixpoint branch instead:
https://github.com/NixOS/nixpkgs/blob/haskellPackagesFixpoint/pkgs/top-level/haskell-packages.nix#L54
I think this works much more elegantly than deepOverride. deepOverride works by
recursively analyzing and overriding paramaters to functions producting
deriviations.
On the otherhand, overrideScope works directly by updating the scope that
callPackages is run in. overrideScope unties the knot that is formed
by the recursive set of packages and lets you update the set before
tying the knot up again and rerunning callPackage.
I'm happy to help make a patch for you.
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell NG
Hi guys,
in the spirit of release early, release often, I'd like to inform everyone
with an interest in the Haskell part of Nixpkgs about the ongoing effort to
re-factor both cabal2nix and the code in Nixpkgs to achieve ...
1) support for all of Hackage,
2) death to the ghc-wrapper, and
3) easier and more reliably customization of the package set.
The Nixpkgs code lives in the haskell-ng branch of my Github clone [1]. In
that branch, Haskell related code is in pkgs/development/haskell-modules:
- hackage-packages.nix is generated automatically by the hackage2nix utility
from the v2.x branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary. (I
need to add code to hackage2nix to configure the choice of generated
packages conveniently.)
Note that a significant portion of those builds will not succeed because
they depend on system libraries that we don't have. Finding those broken
packages and fixing them (or adding meta.broken = true) will need a
community effort once this setup has stabilized. The Hydra job [3] builds
these packages to give us feedback on the state of affairs.
- default.nix imports the contents from hackage-packages.nix, applies (a
sequence of) configuration functions, and makes the result available as a
haskellPackages set suitable for nix-env and friends. The purpose of those
configurations is to adapt the package set for different compiler versions,
i.e. you can think of this file as a simplified version of what used to be
haskell-defaults.nix.
In the new setup, it will no longer be possible to install Haskell libraries
by name: you must access them by their attribute path. This is necessary for
performance reasons, because nix-env won't like us to bring an additional
7000+ packages into scope. The big advantage of this change is that we can
drop all that freaky name-mangling as package names no longer need to be
unique in the global scope.
- generic-builder.nix is a vastly simplified build function for Haskell
packages. It's main feature is that it works with plain GHC -- meaning that
ghc-wrapper is no longer required anywhere in Nixpkgs. Furthermore, builds
are simple non-recursive attribute sets now; there is no more of that
recursive tying-the-knot stuff the old 'cabal' function used to require.
From the user's point of view, there are two important changes:
1) No more ghc-wrapper, i.e. we no longer support non-deterministic setups
where people install random packages into random places and expect them to
know about each other. Instead, 'ghcWithPackages' is the tool of choice to
create a deterministic Haskell environment. I plan to add support to
cabal2nix for generating appropriate build instructions for use with
nix-shell. It might also be nice to have a tool nix-cabal-shall that
combines cabal2nix and nix-shell into one.
2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
non-default version of 'binary'. Then
foo.deepOverride { binary = self.binary_0_4_0_1; };
gives a derivation that uses this particular version to build 'foo' as well
as all of foo's build inputs.
The current state of the repository is work in progress. I don't use this
code for production yet, and neither should you. :-) I just wanted to share the
effort to keep everyone in the loop and to encourage you to provide feedback.
Best regards,
Peter
[1] https://github.com/peti/nixpkgs/tree/haskell-ng
[2] https://github.com/NixOS/cabal2nix/tree/v2.x
[3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
Not related to your central goals (which are awesome), but can we take this
opportunity to dashify attribute names as well?
On Dec 12, 2014, at 2:38 PM, Peter Simons sim...@cryp.to wrote:
Hi guys,
in the spirit of release early, release often, I'd like to inform everyone
with an interest in the Haskell part of Nixpkgs about the ongoing effort to
re-factor both cabal2nix and the code in Nixpkgs to achieve ...
1) support for all of Hackage,
2) death to the ghc-wrapper, and
3) easier and more reliably customization of the package set.
The Nixpkgs code lives in the haskell-ng branch of my Github clone [1]. In
that branch, Haskell related code is in pkgs/development/haskell-modules:
- hackage-packages.nix is generated automatically by the hackage2nix utility
from the v2.x branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary. (I
need to add code to hackage2nix to configure the choice of generated
packages conveniently.)
Note that a significant portion of those builds will not succeed because
they depend on system libraries that we don't have. Finding those broken
packages and fixing them (or adding meta.broken = true) will need a
community effort once this setup has stabilized. The Hydra job [3] builds
these packages to give us feedback on the state of affairs.
- default.nix imports the contents from hackage-packages.nix, applies (a
sequence of) configuration functions, and makes the result available as a
haskellPackages set suitable for nix-env and friends. The purpose of those
configurations is to adapt the package set for different compiler versions,
i.e. you can think of this file as a simplified version of what used to be
haskell-defaults.nix.
In the new setup, it will no longer be possible to install Haskell libraries
by name: you must access them by their attribute path. This is necessary for
performance reasons, because nix-env won't like us to bring an additional
7000+ packages into scope. The big advantage of this change is that we can
drop all that freaky name-mangling as package names no longer need to be
unique in the global scope.
- generic-builder.nix is a vastly simplified build function for Haskell
packages. It's main feature is that it works with plain GHC -- meaning that
ghc-wrapper is no longer required anywhere in Nixpkgs. Furthermore, builds
are simple non-recursive attribute sets now; there is no more of that
recursive tying-the-knot stuff the old 'cabal' function used to require.
From the user's point of view, there are two important changes:
1) No more ghc-wrapper, i.e. we no longer support non-deterministic setups
where people install random packages into random places and expect them to
know about each other. Instead, 'ghcWithPackages' is the tool of choice to
create a deterministic Haskell environment. I plan to add support to
cabal2nix for generating appropriate build instructions for use with
nix-shell. It might also be nice to have a tool nix-cabal-shall that
combines cabal2nix and nix-shell into one.
2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
non-default version of 'binary'. Then
foo.deepOverride { binary = self.binary_0_4_0_1; };
gives a derivation that uses this particular version to build 'foo' as well
as all of foo's build inputs.
The current state of the repository is work in progress. I don't use this
code for production yet, and neither should you. :-) I just wanted to share
the
effort to keep everyone in the loop and to encourage you to provide feedback.
Best regards,
Peter
[1] https://github.com/peti/nixpkgs/tree/haskell-ng
[2] https://github.com/NixOS/cabal2nix/tree/v2.x
[3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
- hackage-packages.nix is generated automatically by the hackage2nix
utility
from the v2.x branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary.
So does the spirit behind hack-nix win finally? Finally? :)
If we rewrite the stuff we should get it right this time.
I feel getting this right means
1) versioning hackage
2) implement a way to retrieve hackage packages (either by api or from
versioned hackage dump)
3) share package resolution with cabal (don't invent our own stuff -
because it will always be a lot of work and be totally different)
AFAIK Shea has added a way to load .dll functions. I think I remember it
is possible to call Haskell from C code. Thus what about collaborating
on the implementation sketched above?
It would serve as sample which could be adopted for the other
universes (perl/python/ruby/java/scala/rust/vim/emacs/whatever).
Thus how could usage look like?
haskellPackages {
hackage-dbs: [
http://some-mirror/version/2014-12-10-hackage-packages.tar.gz;)
my custom stuff
]
resolve: bytestring
}
Due to referencing a hackage like database by date it should be
deterministic.
Fetching all versions of a package could be done by API (HTTP) or such -
thus downloading hackage would no longer be necessary.
Thoughts?
This is the next thing I'd try trying to learn from hack-nix.
For all of you who don't know what hack-nix is: Its a brute for
dependency solver written in Nix reading a hackage database which was
serialized to a .nix file doing exactly what Peter wants to implement:
Latest versions + some manually added older versions to make packages
resolve. Additionally its easy to add your own packages (eg dev
versions) and call the solver as well as patch packages (eg .cabal
files, especially its dependency information) before turning it into a
huge .nix file.
You can find a short description https://nixos.org/wiki/Nixpkgs-haskell-overlay
It was meant to be a proof of concept. Now I'd like to ask you whether
you would prefer joining a common effort which is most likely to work.
Its too painful to role my own solutions for everything (haskell, ruby
overlay etc - even though it often works nicely - and fails due to lack
of man power).
Peter: Please comment on the proposal, I'd rather join than keeping my
own stuff, but your attempt just seems to be another hack-nix with all
of its problems.
Who would join implementing the design I've sketched above?
Live is too short IMHO. My point of view might be limited - thus if I
make any bad assumptions please tell me.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
