[Nix-commits] [NixOS/nixpkgs] a99e4f: scala: put docs in correct subdirectory
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: a99e4f28e95f51a7869a2f95abd7a98bff7093b0 https://github.com/NixOS/nixpkgs/commit/a99e4f28e95f51a7869a2f95abd7a98bff7093b0 Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2017-03-12 (Sun, 12 Mar 2017) Changed paths: M pkgs/development/compilers/scala/default.nix Log Message: --- scala: put docs in correct subdirectory Under NixOS, /run/current-system/sw/share/doc was getting the license file, etc. (cherry picked from commit e333a71478730c63510b48131282f97b5e9c1af9) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Remapping Console Key Bindings
I just realised that the previous advice doesn't work very well after a reboot (no keys work except control). A better way is: 1. dumpkeys > /etc/nixos/keys.map 2. Edit keys.map and change keycode 58 from Caps_Lock to Control. 3. In configuration.nix: i18n.consoleKeyMap = ./keys.map; Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Remapping Console Key Bindings
Hi Mark, This is what I do for caps lock as control key: # configuration.nix i18n.consoleKeyMap = (pkgs.writeText "keys.map" '' keymaps 0-255 keycode 58 = Control ''); It works for the US keyboard layout. If you use another layout, you might want to edit the output of dumpkeys ("kbd" package) yourself, and load that file as i18n.consoleKeyMap. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] de2f9d: haskellPackages.ghcjs-dom: Add overrides (#20474)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: de2f9d67196c05ac9b4efedc7cc880ea1315f7bf https://github.com/NixOS/nixpkgs/commit/de2f9d67196c05ac9b4efedc7cc880ea1315f7bf Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2016-11-21 (Mon, 21 Nov 2016) Changed paths: M pkgs/development/haskell-modules/configuration-ghcjs.nix Log Message: --- haskellPackages.ghcjs-dom: Add overrides (#20474) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Building ghcjs-dom
Hi Ryan, I have been having much fun with reflex-platform, so thanks for that. I think it works because it's using ghcjs-dom 0.2. If reflex-dom starts using ghcjs-dom 0.5, then we will need an answer for this question. Cheers, Rodney On Tue, Nov 01 2016, Ryan Trinkle wrote: > Hi Rodney, > > You could take a look at > https://github.com/reflex-frp/reflex-platform/blob/develop/default.nix . I > didn't realize upstream wasn't building, but I always keep reflex-platform > building (and with binary caches available, see > https://github.com/reflex-frp/reflex-platform/blob/develop/notes/NixOS.md > ). If there's anything in there that can be reused upstream, please feel > free to take the code you need, and I'll help move things upstream however > I can. > > > Best, > Ryan > > On Tue, Nov 1, 2016 at 5:10 AM, Rodney Lorrimar <d...@rodney.id.au> wrote: > >> Hello List, >> >> I would really like this package to build: >> >> nix-build -A pkgs.haskell.packages.ghcjs.ghcjs-dom >> >> I found that the layout upstream has changed, so updated the overrides >> accordingly (see patch below). >> >> My current problem is that it won't build without Cabal >= 1.24. >> >> If I use (addBuildTool super.ghcjs-dom-jsffi [ self.cabal-install ]), >> then it builds Cabal 1.24 as javascript, which is not quite what I want. >> >> Does anyone know how I could make it build? >> >> >> Cheers, >> >> Rodney >> >> >> --- >> pkgs/development/haskell-modules/configuration-ghcjs.nix | 8 ++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/pkgs/development/haskell-modules/configuration-ghcjs.nix >> b/pkgs/development/haskell-modules/configuration-ghcjs.nix >> index c97296c..e56d7eb 100644 >> --- a/pkgs/development/haskell-modules/configuration-ghcjs.nix >> +++ b/pkgs/development/haskell-modules/configuration-ghcjs.nix >> @@ -88,12 +88,16 @@ self: super: >> }) {}; >> >>ghcjs-dom = overrideCabal super.ghcjs-dom (drv: { >> -libraryHaskellDepends = [ self.ghcjs-base ] ++ >> +libraryHaskellDepends = [ self.ghcjs-base self.ghcjs-dom-jsffi ] ++ >>removeLibraryHaskellDepends [ >> -"glib" "gtk" "gtk3" "webkitgtk" "webkitgtk3" >> +"ghcjs-dom-jsaddle" "ghcjs-dom-webkit" >>] drv.libraryHaskellDepends; >>}); >> >> + ghcjs-dom-jsffi = overrideCabal super.ghcjs-dom-jsffi (drv: { >> +libraryHaskellDepends = [ self.ghcjs-base self.text ]; >> + }); >> + >>ghc-paths = overrideCabal super.ghc-paths (drv: { >> patches = [ ./patches/ghc-paths-nix-ghcjs.patch ]; >>}); >> -- >> 2.10.1 >> ___ >> 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
[Nix-dev] Building ghcjs-dom
Hello List, I would really like this package to build: nix-build -A pkgs.haskell.packages.ghcjs.ghcjs-dom I found that the layout upstream has changed, so updated the overrides accordingly (see patch below). My current problem is that it won't build without Cabal >= 1.24. If I use (addBuildTool super.ghcjs-dom-jsffi [ self.cabal-install ]), then it builds Cabal 1.24 as javascript, which is not quite what I want. Does anyone know how I could make it build? Cheers, Rodney --- pkgs/development/haskell-modules/configuration-ghcjs.nix | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/pkgs/development/haskell-modules/configuration-ghcjs.nix b/pkgs/development/haskell-modules/configuration-ghcjs.nix index c97296c..e56d7eb 100644 --- a/pkgs/development/haskell-modules/configuration-ghcjs.nix +++ b/pkgs/development/haskell-modules/configuration-ghcjs.nix @@ -88,12 +88,16 @@ self: super: }) {}; ghcjs-dom = overrideCabal super.ghcjs-dom (drv: { -libraryHaskellDepends = [ self.ghcjs-base ] ++ +libraryHaskellDepends = [ self.ghcjs-base self.ghcjs-dom-jsffi ] ++ removeLibraryHaskellDepends [ -"glib" "gtk" "gtk3" "webkitgtk" "webkitgtk3" +"ghcjs-dom-jsaddle" "ghcjs-dom-webkit" ] drv.libraryHaskellDepends; }); + ghcjs-dom-jsffi = overrideCabal super.ghcjs-dom-jsffi (drv: { +libraryHaskellDepends = [ self.ghcjs-base self.text ]; + }); + ghc-paths = overrideCabal super.ghc-paths (drv: { patches = [ ./patches/ghc-paths-nix-ghcjs.patch ]; }); -- 2.10.1 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] DBus and XMonad
On Wed, Oct 19 2016, Rodney Lorrimar wrote: > My next problem is that gnome-terminal will no longer start: > > dbus-daemon[6158]: Activating via systemd: service > name='org.gnome.Terminal' unit='gnome-terminal-server.service' > dbus-daemon[6158]: Activation via systemd failed for unit > 'gnome-terminal-server.service': Unit gnome-terminal-server.service not found. > > I have found that this is due to > https://github.com/NixOS/nixpkgs/issues/19110 > > My workaround for that problem is simply: > > ln -vsf /run/current-system/sw/lib/systemd/user/* ~/.config/systemd/user Hello List, The submitter of #19110 notes that another way to get the user service to start would be to configure this: systemd.packages = [ pkgs.gnome3.gnome_terminal ]; However I'm not sure whether it's a good solution. This would mean every program which provides a dbus-activated systemd user service needs to added to NixOS systemd.packages. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] DBus and XMonad
On Wed, Oct 19 2016, Ruben Astudillo wrote: > On 19/10/16 08:19, Michael Alan Dorman wrote: >> Rodney Lorrimar <d...@rodney.id.au> writes: >>> >>> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5;unix:abstract=/tmp/dbus-BjlHWWC2xz,guid=3733c1a431ad4cb309cc622a580747a5 >>> >>> I'm not quite sure why the dbus socket was unavailable, but my solution >>> was to enable services.dbus.socketActivated in configuration.nix. >> >> I have seen this, too---manifesting as an taffybar not starting---though >> I was doing some more investigation before I enquired. >> >> I was able to roll back to a version that worked, and the clearly >> distinguishing feature was that there was only one listing in >> DBUS_SESSION_BUS_ADDRESS; and indeed, if I set the environment variable >> when starting taffybar, it works fine. >> >> $ >> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5 >> taffybar >> >> Works just fine. >> >> I guess the question I'm left with is whether the error is in the nix >> configuration providing us with two entries in the variable, or in the >> haskell dbus package in not handling it properly? > > I've noticed this too (and fixed the same way). Before in 16.03 > DBUS_SESSION_BUS_ADDRESS only listed one abstract path, thus I it isn't > a fault on the haskell side of things. Hi, I guess it must have been a change in either dbus-launch or the dbus daemon. The current freedesktop.org implementation handles semicolons in DBUS_SESSION_BUS_ADDRESS. It also adds the user bus socket to the list of addresses (if it exists). I have reported these two things to the haskell-dbus author. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] DBus and XMonad
Hello List, I've recently had some troubles starting up my gnome3 + XMonad desktop session. My first problem was that Taffybar and xmonad.hs were unable connect to DBus with the following error: connectSession: DBUS_SESSION_BUS_ADDRESS is missing or invalid. The value of DBUS_SESSION_BUS_ADDRESS probably came from dbus-launch: DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5;unix:abstract=/tmp/dbus-BjlHWWC2xz,guid=3733c1a431ad4cb309cc622a580747a5 I'm not quite sure why the dbus socket was unavailable, but my solution was to enable services.dbus.socketActivated in configuration.nix. An additional problem is that the haskell-dbus library won't check the socket $XDG_RUNTIME_DIR/bus after the connection fails using DBUS_SESSION_BUS_ADDRESS. So my workaround is to change the environment before connecting: let bus d = "unix:path=" ++ d ++ "/bus" maddr <- fmap bus <$> lookupEnv "XDG_RUNTIME_DIR" case maddr of Just addr -> setEnv "DBUS_SESSION_BUS_ADDRESS" addr Nothing -> return () This allows me to start xmonad and taffybar. My next problem is that gnome-terminal will no longer start: dbus-daemon[6158]: Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' dbus-daemon[6158]: Activation via systemd failed for unit 'gnome-terminal-server.service': Unit gnome-terminal-server.service not found. I have found that this is due to https://github.com/NixOS/nixpkgs/issues/19110 My workaround for that problem is simply: ln -vsf /run/current-system/sw/lib/systemd/user/* ~/.config/systemd/user Now I have a working desktop session again. I have posted this in case anyone else has similar difficulties. In future, having a socket-activated dbus would allow the NixOS xsession script to be partly replaced by systemd. I think that could be quite exciting. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 246c93: pump.io: git-2015-11-09 -> 1.0.0
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 246c9375996e3bf5af8c1f2f8179390ee63a950a https://github.com/NixOS/nixpkgs/commit/246c9375996e3bf5af8c1f2f8179390ee63a950a Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2016-10-10 (Mon, 10 Oct 2016) Changed paths: A pkgs/servers/web-apps/pump.io/composition.nix M pkgs/servers/web-apps/pump.io/default.nix A pkgs/servers/web-apps/pump.io/generate.sh M pkgs/servers/web-apps/pump.io/node-packages.json M pkgs/servers/web-apps/pump.io/node-packages.nix Log Message: --- pump.io: git-2015-11-09 -> 1.0.0 cherry-pick from 983f6819c7d0bf9692df591f2ce25e2122a24434 because of security issue. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] Three questions about node2nix
Hello List and Sander, It's nice to see the all good work done to keep up with the node.js enchilada. I have a few questions about what this means for packages in the nixpkgs collection. 1. Should pkgs/top-level/node-packages.{nix,json} be removed now? 2. Because I would like to update bower2nix from 3.0.1 -> 3.1.0, I run pkgs/development/node-packages/generate.sh. (I noticed that this script could include the special nix-shell shebang to ensure node2nix is available when running the script). Is it possible/desirable to limit version changes to just bower2nix and maybe its direct dependencies -- to minimize possible disruption to other nodePackages. This whole topic is a can of worms of course. 3. I "maintain" another node.js package -- pump.io -- which I'm unsure what to do with. I was probably too eager to PR this into the nixpkgs collection in the first place. It recently had a 1.0.0 release which contains security-relevant fixes. If I update to 1.0.0 it means dumping another 112K of fluff into our git repo. This might be OK if it were for a decent language's package system, or if the software had lots of users. I think the best course of action is to remove the pump.io module and package from the main nixpkgs collection. Then maybe put it back when it's possible to generate derivations directly from a shrinkwrap.json. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 0227c9: nodePackages.bower2nix: Add back PATH wrapping
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 0227c99c1582ce362449f086502037605fe6cf07 https://github.com/NixOS/nixpkgs/commit/0227c99c1582ce362449f086502037605fe6cf07 Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2016-09-15 (Thu, 15 Sep 2016) Changed paths: M pkgs/development/node-packages/default-v4.nix M pkgs/development/node-packages/default-v5.nix M pkgs/development/node-packages/default-v6.nix Log Message: --- nodePackages.bower2nix: Add back PATH wrapping bower2nix and fetch-bower need git in the PATH to operate. This wrapping got lost with the nodePackages updates. (Fixes #18454) (cherry picked from commit 952c477f901f35a99758bcc8fdf8b685ad8fa3e0) Commit: 35a87e41d59f9e7d0479a6c7a0eff787b6d29ed5 https://github.com/NixOS/nixpkgs/commit/35a87e41d59f9e7d0479a6c7a0eff787b6d29ed5 Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2016-09-15 (Thu, 15 Sep 2016) Changed paths: M pkgs/development/node-packages/node-packages-v4.nix M pkgs/development/node-packages/node-packages-v5.nix M pkgs/top-level/node-packages-generated.nix Log Message: --- nodePackages.bower2nix: 3.0.1 -> 3.1.1 (cherry picked from commit 131b8d4edb39d302db64ff284a7f5863d2d53522) Compare: https://github.com/NixOS/nixpkgs/compare/c000c2fa71e3...35a87e41d59f___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Three questions about node2nix
Hi Sander, (Apologies to nix-dev who didn't receive my original message because I sent it with the wrong address) On Sun, Sep 11 2016, Sander van der Burg wrote: > 1. Not yet, it will break a couple of non-NPM packages that have > dependencies on them. I'm still in the progress of replacing them, but this > will take some time. Once these packages have been fixed, the old npm2nix > package set is obsolete. Ah yes I see now -- I was only looking in all-packages.nix. > 2. At the moment no. Ideally, it would be better to have a more > sophisticated approach that would only regenerate affected pieces while > leaving others intact. I believe this is something nixfromnpm implements, > but node2nix does not having something like that. Maybe, it seems like a lot of work to implement. IMO, the ideal situation is that each node.js program is nix-shrinkwrapped, but without the enormous amount of fluff in the main repo (fluff in auxiliary repos would be fine). > 3. This is indeed one the packages I have encountered that need to be > fixed. Unfortunately, one of node2nix's undesired side effects is that is > generates a lot of code churn when updating the package set. I guess for > now we just have to live with it. I'm not sure whether it's worth the trouble, but could the code churn be mitigated slightly by using a compact generated format -- e.g. { buildNP, np }: buildNP { name = "generated-node-packages"; parts = [ (np "colors" "0.6.0-1" "6dbb68ceb8bc60f2b313dcc5ce1599f06d19e67a") (np "ejs" "2.3.4" "3c76caa09664b3583b0037af9dc136e79ec68b98") # ... ]; } > If it's ok to remove pump.io, then I will do it. We can always readd it > later. I'm pretty sure it's OK to remove pump.io. I can make the PR and add something to the release notes about it. Cheers, Rodney > On Sun, Sep 11, 2016 at 2:00 PM, Rodney Lorrimar <rod...@rodney.id.au> > wrote: > >> Hello List and Sander, >> >> It's nice to see the all good work done to keep up with the node.js >> enchilada. I have a few questions about what this means for packages in >> the nixpkgs collection. >> >> 1. Should pkgs/top-level/node-packages.{nix,json} be removed now? >> >> 2. Because I would like to update bower2nix from 3.0.1 -> 3.1.0, I run >>pkgs/development/node-packages/generate.sh. >> >>(I noticed that this script could include the special nix-shell >>shebang to ensure node2nix is available when running the script). >> >>Is it possible/desirable to limit version changes to just bower2nix >>and maybe its direct dependencies -- to minimize possible disruption >>to other nodePackages. This whole topic is a can of worms of course. >> >> 3. I "maintain" another node.js package -- pump.io -- which I'm unsure >>what to do with. I was probably too eager to PR this into the nixpkgs >>collection in the first place. >> >>It recently had a 1.0.0 release which contains security-relevant >>fixes. >> >>If I update to 1.0.0 it means dumping another 112K of fluff into our >>git repo. This might be OK if it were for a decent language's package >>system, or if the software had lots of users. >> >>I think the best course of action is to remove the pump.io module and >>package from the main nixpkgs collection. Then maybe put it back when >>it's possible to generate derivations directly from a shrinkwrap.json. >> >> >> Cheers, >> >> Rodney >> ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 553750: nixos/tests/pump.io: Fix systemd unit config
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 5537503dec1af5dfa6392b7673420042878d659f https://github.com/NixOS/nixpkgs/commit/5537503dec1af5dfa6392b7673420042878d659f Author: Rodney Lorrimar <d...@rodney.id.au> Date: 2016-09-08 (Thu, 08 Sep 2016) Changed paths: M nixos/tests/pump.io.nix Log Message: --- nixos/tests/pump.io: Fix systemd unit config Ref #18209 (cherry picked from commit 3fd603c02f339778c8ea24c2fadacb91185eb1c7) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Locking issues with Nix
On Tue, Aug 09 2016, Guillaume Maudoux (Layus) wrote: > With my current version of nix, I observe the following behaviour after some > calls to nix: > The command hangs forever. > > $ nix-build ... > these derivations will be built: > /nix/store/-.drv > waiting for locks or build slots... I was experiencing such problems in June, but can't exactly remember what I did to fix it. The waiting for build slots message occurred because the nix-daemon processes were impossible to kill. I had these messages in my log: Jun 07 14:14:16 aurora kernel: INFO: task nix-daemon:8376 blocked for more than 120 seconds. I think it was something that I had mounted because df would also hang in the same way. Sorry for the vagueness, hope it gives you a clue. Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Windows updates
I have to agree that it's awesome. Two amazing examples which come to mind are: 1. Using nix for reproducible Windows builds within Linux, including a derivation which installs Windows from an iso into a VM image. (Unfortunately I was never able to try this because I couldn't obtain an iso and license key). 2. The NixOS test suite. In nixpkgs/nixos/tests/quake3.nix there is a test which actually starts a quake3 server with bots and joins two separate players into the game. It checks that the players joined successfully and then takes screenshots of players being fragged by bots. So my question is, why play games yourself on Windows when you can automate it with Nix? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Building with default.nix
Le mardi 09 août 2016 à 18:04 +0200, Lancelot SIX a écrit: > You could have a `shell.nix` file as follows: > > import ./default.nix { sampleproject = { outPath = ""; name = > "sampleproject"; } ; } > > This is hacky but with that you will not copy the project tree into > the nix store when runninx `nix-shell` (this will only be done when > running `nix-build`). I think this is half way to what you are looking > for. > > Hope this helps. Hi, It does help a little thanks, except in my real project, the shell derivation depends on the project sources to set up some tools. I was (ab)using the src.outPath attribute to avoid copying of src into the nix store. Like this: # testScript is a buildInput of the shell derivation testScript = mkDerivation { name = "realproject-test"; src = realproject.outPath + "/scripts/test"; buildCommand = "mkdir -p $out/bin && cp $src $out/bin/test"; }; I don't mind copying the project sources into the nix store before starting a nix-shell. In fact it's a good thing, if the shell depends on project sources. But I would like to filter the files copied so that it's just git-tracked files and not random cruft. I saw a recent commit 39e689e "cleanSource: filter out also nix result symlinks (#16120)" which seems to address the same issue. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Locking issues with Nix
Just to CC nix-dev, I added a comment here: https://github.com/NixOS/nix/issues/1015#issuecomment-239088681 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Building with default.nix
Hello nix-dev, I was wondering, what is the best way to develop a project outside of nixpkgs? My current method is something like this: # default.nix { sampleproject ? { outPath = ./.; name = "sampleproject"; } , pkgs ? import {} }: with pkgs.python35Packages; buildPythonPackage rec { name = "sampleproject-${version}"; version = "1.2.0"; src = [ sampleproject ]; propagatedBuildInputs = [ peppercorn ]; }; (Full project example here: https://github.com/rvl/sampleproject) In many ways it works well, but I'm not entirely happy. The problem is that my entire work tree (and all the accumulated project cruft) gets copied into the nix store every time I run nix-build or nix-shell. This is slow and also prints the scary "may run out of memory" warning. Is there a function to load only the tracked files from a git work tree? Ideally this function would result in same store path if the files are the same, so nothing need be rebuilt if no sources changed. Cheers, Rodney ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev