Update tags to support Go modules

[tiziano88]

Update tags to support Go modules

[daved]

Setting GO111MODULE=off is the obvious solution, but I'd rather avoid polluting my GOPATH. I will try with a temporary GOPATH for now.

[davcamer]

I appear to have successfully done this by running
go get github.com/tiziano88/[email protected]

That command added
github.com/tiziano88/elm-protobuf v0.0.5-0.20180917212848-43b6ec64321b
to the require section of my go.mod file.

To "pin" that version (I am also vendoring) I also added a
github.com/tiziano88/elm-protobuf => github.com/tiziano88/elm-protobuf v0.0.5-0.20180917212848-43b6ec64321b
to the replace section of go.mod. This last part is probably unnecessary but I don't want a go mod tidy or other command to reset the version to the seemingly compatible v0.0.4 tag. Since this old tag is in the format that go modules expects, it confuses the tools.

We also have a "tools.go" file as described on the modules wiki.

// +build tools

package grpc

import (
	// We are using 3.0.0 tag of this dependency, but the convention of using a
	// versioned path like "github.com/tiziano88/elm-protobuf/v3" doesn't work.
	// This is expected since it is not (yet?) a proper go module. This is
	// exacerbated by an old "v0.0.4" tag in the repository, which the go tools
	// incorrectly recognize as a pre-release module tag.
	//
	// Instead, there is a replace directive in the go.mod file to pin the
	// correct module incompatible version.
	_ "github.com/tiziano88/elm-protobuf/protoc-gen-elm"
)

I think the newer tags are in the format they are in for the sake of the elm packaging tools. Maybe dual tags are needed? But a go.mod file would be needed as well to really make this compatible with go's packaging tools.

Isn't it funny how Elm packages are to Elm modules the same way go modules are to go packages? 😆

[tiziano88]

Thanks for the comments, I have not been following the latest on Go module management, if anyone wants to suggest a fix I am happy to implement it!