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.
