[PATCH] Adopt Go workspace best practices

Jörg Thalheim joerg at higgsboson.tk
Mon May 21 14:46:02 CEST 2018



On 2018-05-20 19:57, Filippo Valsorda wrote:
> Relative imports break when the project is built from within GOPATH,
> where most Go developers prefer to develop:
>
>     device.go:10:2: local import "./ratelimiter" in non-local package
>     tun_darwin.go:10:2: local import "./rwcancel" in non-local package
>     noise-protocol.go:10:2: local import "./tai64n" in non-local package
>     cookie.go:10:2: local import "./xchacha20poly1305" in non-local package


We also carry a patch for this in nixpkgs for that reason:
https://github.com/NixOS/nixpkgs/commit/b599f672e44270d2c6154b7855ddec11e4d43a93#diff-b3f319067b7e71fdd1f6b94ef51a983aR17

>
> On the other hand, the vendor folder is not supported outside of
> GOPATH, so it's unclear how/if that ever worked.
>
> Moreover, using go get instead of dep means that dependencies are not
> pinned, and HEAD is used instead, which makes builds unreproducible.
>
> This adds a Makefile that creates a local GOPATH with a symlink
> trick, so developing outside GOPATH still works. Not only that, but
> a system GOPATH is not required at all as long as the Makefile is used.
> And if the project is cloned in the right place in GOPATH all standard
> tools will work as expected.
>
> So all workflows should work just as weel or better. The only new
> requirement is dep, but that's unavoidable for reproducible builds.
>
> Finally, run goimports on all files to format import statements.
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard



More information about the WireGuard mailing list