Meaning when both src and modules comes from the same call to `gomod2nix generate` like so:
``` bash
$ gomod2nix generate github.com/simeji/jid/cmd/jid
```
Bug:
Due to the way `buildGoDir` function was repurposed to also run `go
test`, if `checkFlags` was defined, `go test` was ran only at the top
level directory. Only the first element of `checkFlags` array would get
passed to the `go test` command as arguments.
Fix:
Now the first parameter to `buildGoDir` is handled as the command. If
the command is "test" `checkFlags` get passed as arguments along with
other build flags like ldflags, tags, etc.
Readability:
- Iteratively build a flag array in `buildGoDir` instead of single long
variable expansion command line.
- Bash style: Single line local assignment of positional parameters.
This is a port of 89864413b2.
The exclusion logic was moved out of getGoDirs but only buildPhase was updated
causing checkPhase to possibly fail. This happened in golint as it has go
files in testdata that are meant as testdata files and not go packages to
test which caused the checkPhase to fail.
This is a port of ddcc7c67d2
There's no backslash interpretation going on within single-quote strings
which means there's no need to escape the backslash. Since this was going
on within single-quote strings the $exclude variable ended up having 2
backslashes (`\\`) instead of the intended single backslash. This meant
that the regex that was built up was incorrect. For example prometheus'
exclude contents before and after this change are:
✕: \(/_\|examples\|Godeps\|testdata\\|documentation/prometheus-mixin\)
✓: \(/_\|examples\|Godeps\|testdata\|documentation/prometheus-mixin\)
This is a port of 60543c4f9e
Few things going on in this commit:
Do not print "Building subPakage $pkg" message if actually going to skip the
package. This was confusing to me when I was trying to figure out how to set
excludedPackages and seeing the "Building subpackage $pkg" messages for
packages I wanted to skip. Turns out this messages was being printed before
checking if we actually wanted to build the package and not necessarily that my
excludedPackages was wrong.
This commit also does some setup outside the buildGoDir function so that we
avoid checking `excludedPackages` for every package and cut down the number
of grep calls by half since we always want at least one grep for the default
excludedPackages, might as well just add to the patterns being checked.
Finally, adds documentation for usage of excludedPackages and subPackages. I
had to read the implementation to figure out how to correctly use these
function arguments since there was no documentation and different uses in the
code base. So this commit documents usage of the arguments.
This is a port of 8b5a7940b0
Simpler method of setting tags rather than using some combination of buildFlags, buildFlagsArray, preBuild, etc
Using `lib.concatStringsSep ","` as space separated tags are deprecated in go.
This is a port of b60dde0c1e
Previously it was not possible to define multiple ldflags, since only
the last definition applies, and there's some quoting issues with
`buildFlagsArray`. With the new `ldflags` argument it's possible to do
this, e.g.
ldflags = drv.ldflags or [] ++ [
"-X main.Version=1.0"
]
can now properly append a flag without clearing all previous ldflags.
This is a port of 155ae682a5
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.
