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