On Mon 03 Jul 2017 at 15:38, Harmen <har...@lijzij.de> wrote:

> On Mon, Jul 03, 2017 at 03:27:34PM +0200, Tomas Hlavaty wrote:
>> Hi Harmen,
>> On Mon 03 Jul 2017 at 15:19, Harmen <har...@lijzij.de> wrote:
>> > I can't be the first to want to use fetchgitPrivate with a sandboxed
>> > nix-daemon. Any experiences or tips?
>> I had it working but there are several cases which needs extra setup
>> that I recommend to avoid fetchgitPrivate and use source variables,
>> e.g. src = <proprietarySrc>; This works the same in any context, e.g. in
>> hydra, without hydra, etc.  You just need to set the proprietarySrc
>> accordingly.
> could you be a bit more specific what you mean?

Have a look at NIX_PATH: https://nixos.org/nix/manual/#env-NIX_PATH

You can configure the NIX_PATH locally, e.g.

export NIX_PATH=proprietarySrc=$HOME/src/proprietary:$NIX_PATH

or explicitly via command-line arg to nix-build, nix-shell etc.

Then instead of writing your package as:

stdenv.mkDerivation rec {
  src = fetchgitPrivate ...;


stdenv.mkDerivation rec {
  src = <proprietarySrc>;

If used in the context of hydra, hydra configuration says, where and how
to obtain that software, then hydra downloads it and passes it further
for build.  E.g. in
<https://hydra.nixos.org/jobset/nix/master#tabs-configuration>, there
are paths nix and nixpkgs, which are then written in nix as <nix> and
<nixpkgs> respectively.  In this example, no fetchgitPrivate is used but
you can see those paths.  In your case of proprietary package, you don't
have to do anything special except allowing hydra to download those
proprietary repos.  We have a read-only access to our git repo with ssh
key for hydra.

If you go with the fetchgitPrivate option, you have to grant access in
too many places, i.e. in every context where your package can be
nix-dev mailing list

Reply via email to