The difference in behaviour was unfortunate.
The only downside I can see is that this doesn't allow for mixed
origins in the same package, which probably shouldn't be done anyway.
This makes it possible to generate packages that you do not have a
local checkout for, e.g. running:
`gomod2nix generate --outdir example/ golang.org/x/tools/cmd/stringer`
This will be useful for packaging dependencies that you are not
developing, but just simply packaging.
This creates an `mkGoEnv` function which takes care of adding the
correct Go package to your development environment and installs
development dependencies from tools.go in a Nix derivation.
The "normal" workflow around Go with tools.go just sticks development
dependencies in $GOBIN which isn't ideal since you have no separation
between projects.
Constructs such as
```
replace google.golang.org/grpc => google.golang.org/grpc v1.33.2
replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1
```
Are perfectly valid and we previously discarded every one but the last of them.
This fixes relative path modules not being correctly vendored by
parsing go.mod in Nix and vendoring them into the correct directory in
the Nix sandbox.
Ideally this should also come with a pluggable source filtering
mechanism and/or maybe use any present gitignore files like
poetry2nix does.
To use this new feature you have to pass a new `pwd` param to
`buildGoApplication` as such:
```
buildGoApplication {
pname = "foo";
version = "bar";
pwd = ./.;
src = lib.cleanSource ./.;
}
```
Fixes#2
