This line looks odd, because I didn't find any way to escape ${ inside a Nix string.

The documentation says to put a \ in front of it but this did not work for me, still yielding unexpected $undefined error.

Use the nix string open / close symbol to escape, ex ''${}
On Sun, Feb 28, 2016 at 8:25 PM Valérian Galliat notifications@github.com
wrote:

In pkgs/applications/version-management/gogs/default.nix
#13566 (comment):

+with goPackages;
+
+buildGoPackage rec {

• name = "gogs-${version}";
• version = "20160227-${stdenv.lib.strings.substring 0 7 rev}";
• rev = "d320915ad2a7b4bbab075b98890aa50f91f0ced5";

• buildInputs = [ makeWrapper go ];
• buildFlags = lib.optional (sqliteSupport) "-tags sqlite";
• goPackagePath = "github.com/gogits/gogs";

• postInstall = ''
• wrapProgram $bin/bin/gogs \

•  --prefix PATH : ${git}/bin \
  

•  --run 'export GOGS_WORK_DIR=${"$" + "{"}GOGS_WORK_DIR:-$PWD}' \
  

This line looks odd, because I didn't find any way to escape ${ inside a
Nix string.

The documentation http://nixos.org/nix/manual/#idm46912467695696 says
to put a \ in front of it but this did not work for me, still yielding unexpected
$undefined error.

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/pull/13566/files#r54368220.

Thanks!

I don't understand why this exists? Patching default.nix is a bit odd.

@joachifm default.nix is generated by go2nix, but it cannot guess the postInstall hook required to wrap Gogs (because it's specific to Gogs), nor the optional SQLite support with an argument.

That's why, when auto-generating default.nix using gogs-derivation.nix, I patch the output of go2nix to include the sqliteSupport argument, and postInstall hook, which makes the final default.nix.

All of this is done inside nix-build --no-out-link gogs-definition.nix.

Maybe I could achieve the same by having the raw output of go2nix in default-generated.nix, and overriding it in default.nix to add sqliteSupport and postInstall?

This seems a bit complex for my tastes, but I'm simply not qualified to comment on go packaging, sorry.

cc @vcunat @domenkozar

I immediately don't see any better way than this.

I also didn't know about go2nix, so perhaps its users might have a better idea how to handle such a situation. Maybe @cstrahan?

Thanks a lot @cstrahan, I think it's possible to override the go2nix output to add the postInstall hook, and tweak the buildFlags, it's indeed a lot cleaner than patching default.nix.

However the conditional sqliteSupport is a bit trickier, since it needs to remove an entry from extraSrcs if sqliteSupport is false, and extraSrcs is an argument to buildGoPackage, but not an attribute of the actual derivation, so I think that lib.overrideDerivation will not help. I can just ignore this part, it will result in downloading an unnecessary Go package if sqliteSupport is false which is not that bad.

But if anyone have an idea how to gracefully handle this with overriding, I would happily take it. 😄

I agree that generated defaults should be easily overridable. I'll look at haskell stuff and try to make it better.

I tried to separate default.nix from generated one in kamilchm/go2nix#10 but it looks like the allowGoReference flag doesn't work :/
Is there a better way to override generated file than import?

@kamilchm Oh, nice! But yes allowGoReference is an argument of buildGoPackage and lib.overrideDerivation allows only to custom the derivation attributes.

Is there some kind of override mechanism in Nix that would allow to customize the arguments to the buildGoPackage call?

An idea would be to tweak the generated.nix like this:

{ stdenv, lib, goPackages, fetchgit, fetchhg, fetchbzr, fetchsvn, args }:

with goPackages;

buildGoPackage (rec {
  name = "go2nix-${version}";
  # ...
} // args)

And call it like this:

callPackage ./generated.nix {
  args = {
    allowGoReference = true;
    # ...
  };
}

Or even allow to pass these arguments in the top-level function instead of the args set, like @cstrahan suggested, if I understood well? Something like the following example would avoid listing explicitly all possible overridable attributes, but I don't like this filterAttrs call, maybe there's a better way to get all the remaining args).

{ stdenv, lib, goPackages, fetchgit, fetchhg, fetchbzr, fetchsvn, ... } @ args:

with goPackages;

buildGoPackage (rec {
  name = "go2nix-${version}";
  # ...
} // (lib.filterAttrs (n: v: n != "lib" && n != "stdenv" && n != "goPackages" && n != "fetchbzr" && n != "fetchgit" && n != "fetchsvn" && n != "fetchhg") args))

@cstrahan what do you think about these options?