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
