go-modules/generic: add missing PATHs to GOPATH when using nix-shell #26176
Conversation
|
@qknight, thanks for your PR! By analyzing the history of the files in this pull request, we identified @wkennington, @ehmry and @lethalman to be potential reviewers. |
| @@ -198,7 +198,7 @@ go.stdenv.mkDerivation ( | |||
| ln -s "${dep.src}" "$d/src/${dep.goPackagePath}" | |||
| '' | |||
| ) goPath) + '' | |||
| export GOPATH="$d:$GOPATH" | |||
| export GOPATH=${lib.concatStringsSep ":" ( ["$d"] ++ ["$GOPATH"] ++ ["$PWD"] ++ extraSrcPaths)} | |||
There was a problem hiding this comment.
(12:47) < qknight_> if 'go build' yields: cannot find package "nixcloud/backend/root" in any of and my project is src/nixcloud/backends then i simply lack a entry in GOPATH with the absolute path to the
parent of 'src', right?
(12:47) < qknight_> because if i add this, it compiles
(12:47) -!- Poky [~michal@ip-89-177-75-53.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds]
(12:48) < qknight_> so that said, the project root must always be part of the GOPATH or is that wrong?
(12:48) -!- mperillo [~mperillo@host169-59-dynamic.43-79-r.retail.telecomitalia.it] has joined #go-nuts
(12:48) < acln> qknight_: that is correct, all of your Go code usually lives under GOPATH.
There was a problem hiding this comment.
Usually this is up to the user to set this and people might have different opinions how they organize their GOPATH.
Some may create one GOPATH per project others might use one global GOPATH for all go code (https://github.com/golang/go/wiki/GOPATH#use-a-single-gopath).
There was a problem hiding this comment.
@zimbatm might also have an opinion on that.
There was a problem hiding this comment.
@Mic92
do you think your usecase your one global GOPATH fits the concept of using nix-shell? isn't nix-shell usually used an a 'per project' basis?
the shellHook is only used for nix-shell on interactive shells for hacking and not for nix-build like scenarios.
There was a problem hiding this comment.
Isn't that a vendor/ use case? Like for example https://github.com/hashicorp/consul/tree/master/vendor ?
There was a problem hiding this comment.
@qknight all my go projects are checked out inside of $GOPATH, that's what most go projects assume.
To be fair it sucks, I don't think that a project should be influencing anything external to it's repository. This and vendor/ all the project dependencies.
There was a problem hiding this comment.
@qknight After thinking about it, it is a sane default. If someone would have a GOPATH set, it would still do things as before. Otherwise it writes to the nix-shell invocation directory.
There was a problem hiding this comment.
@kamilchm also ok with this PR? if so i will merge it.
There was a problem hiding this comment.
Let's do it. You can't break Go dependency resolution more :/
It will have even more corner cases with Go 1.8 https://beta.golang.org/doc/go1.8#gopath
Motivation for this change
using
nix-shellfor hacking on my go project is nice but after hours of debugging i found that two GOPATHS would always be missing:this PR fixes it by adding both into GOPATH when using
nix-shell.i've tested it with
nixcloud-backendand it works nicely. also, usingnix-buildinstead ofnix-shellis not affected from this change at all.Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)