Support go modules

[Scapal]

Support go module versioning conventions and when used don't redirect to gopkg.in/mail.v2

https://github.com/golang/go/wiki/Modules#semantic-import-versioning

[ivy]

@Scapal Thanks for opening this issue. We had some discussion in #35 about this, but I think it's worth revisiting. I'll look into this more soon. 😄

[ivy]

@Scapal I just tagged v2.3.0 with support for Go modules. Let me know if this fixes your issue.

[markbates]

This has broken both modules and go get. :(

According to the go.mod if using modules you must import with github.com/go-mail/mail/v2 however, if you doing that it breaks go get as there is no path on GitHub to match that.

It's important that the module name also match the import path for those not currently using modules, which is a lot of people.

The suggested route to solve this problem is to create a /v2 folder in the repo, that contains the v2 module and code. This allows for people to migrate to /v2 at their leisure, while not breaking those trying to support both go modules and go get.

Please consider either rolling back this change or making the suggested corrections. Thanks.

This release has broken https://gobuffalo/buffalo.

[ivy]

@markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too:

Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above).

---

Also, from looking at your commit in gobuffalo/buffalo@95c2e1a, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional?

To use this fork, you'll want to import either:

• github.com/go-mail/mail - This should be the latest HEAD of the v2 branch.
• github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.*.* tag.
• gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch.

I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅

[markbates]

Also, the branch “solution” means no one using non-modules can get it with go get. It’s your repo and you can’t obviously, support modules the way you want, but it would be nice if you can make it work for everyone. Thanks.

…

On Nov 12, 2018, 12:57 PM -0500, Ivy Evans ***@***.***>, wrote: @markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too: > Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above). Also, from looking at your commit in ***@***.***, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional? To use this fork, you'll want to import either: • github.com/go-mail/mail - This should be the latest HEAD of the v2 branch. • github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.*.* tag. • gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch. I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[markbates]

We tried using http://gopkg.in/mail.v2 too, but again, modules and import paths don’t match. The problem here is there needs to be a single import path that works for non-modules and modules alike. Currently it’s not possible to import this package and have it resolve in both. They have to match for Go to work. We ended up having to internalize the package as it’s broken.

…

On Nov 12, 2018, 12:57 PM -0500, Ivy Evans ***@***.***>, wrote: @markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too: > Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above). Also, from looking at your commit in ***@***.***, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional? To use this fork, you'll want to import either: • github.com/go-mail/mail - This should be the latest HEAD of the v2 branch. • github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.*.* tag. • gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch. I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ivy]

@markbates I understand your frustration and I want to help. A number of users have expressed interest in utilizing Go modules and I'm only supporting it under the condition that it works for everyone. I want to find a solution that works for us all and in order to do that, I need a bit more detail…

• What go version are you using?
• What exact error messages are you getting?

---

I just tried importing go-mail with a pristine GOPATH without any trouble. One hiccup I noticed, however was that I needed my project to reside within GOPATH, otherwise I get:

go: finding gopkg.in/mail.v2 v2.3.0
go: downloading gopkg.in/mail.v2 v2.3.0
build mytest: cannot find module for path gopkg.in/mail.v2

After making sure my project was moved/symlinked into GOPATH, I had no trouble outside of a small warning:

go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
	ignoring ../../../go.mod;
	see 'go help modules'
Fetching https://gopkg.in/mail.v2?go-get=1
Parsing meta tags from https://gopkg.in/mail.v2?go-get=1 (status code 200)
get "gopkg.in/mail.v2": found meta tag get.metaImport{Prefix:"gopkg.in/mail.v2", VCS:"git", RepoRoot:"https://gopkg.in/mail.v2"} at https://gopkg.in/mail.v2?go-get=1
gopkg.in/mail.v2 (download)
gopkg.in/mail.v2
test

Is this the same case for you too?

Edit: I pasted the wrong go get output.

[ivy]

@markbates It might also help to see the output of pwd and go env.

[markbates]

With mods on (off works fine):

go get gopkg.in/mail.v2

go: gopkg.in/mail.v2@v2.3.0: go.mod has non-....v2 module path "github.com/go-mail/mail/v2" at revision v2.3.0
go: error loading module requirements

With mods off (mods are fine):

go get github.com/go-mail/mail/v2

package github.com/go-mail/mail/v2: cannot find package "github.com/go-mail/mail/v2" in any of:
	/usr/local/go/src/github.com/go-mail/mail/v2 (from $GOROOT)
	/Users/markbates/Dropbox/go/src/github.com/go-mail/mail/v2 (from $GOPATH)

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/markbates/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/markbates/Dropbox/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/markbates/Dropbox/go/src/github.com/gobuffalo/buffalo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2 -w"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zj/ktv0trrj4l79dfq0dkm1b6d40000gn/T/go-build141527679=/tmp/go-build -gno-record-gcc-switches -fno-common"

It's easy to reproduce. You just need to pick an import path, and support that one.

[markbates]

I’m also in my GOPATH as I work exclusively there. This was also reported by other members of the team, the community, Travis, etc... Trust me when I say this broke stuff for people. This got released and all of a sudden everything came to grinding halt. You also can’t rever the change now either as go modules will pick up the last release with a go.mod file; so you can’t revert and need to fix the problem head on.

…

On Nov 12, 2018, 1:20 PM -0500, Ivy Evans ***@***.***>, wrote: @markbates I understand your frustration and I want to help. A number of users have expressed interest in utilizing Go modules and I'm only supporting it under the condition that it works for everyone. I want to find a solution that works for us all and in order to do that, I need a bit more detail… • What go version are you using? • What exact error messages are you getting? I just tried importing go-mail with a pristine GOPATH without any trouble. One hiccup I noticed, however was that I needed my project to reside within GOPATH, otherwise I get: main.go:7:2: cannot find package "gopkg.in/mail.v2" in any of: /usr/local/Cellar/go/1.11.2/libexec/src/gopkg.in/mail.v2 (from $GOROOT) /Users/ivy/test/go/src/gopkg.in/mail.v2 (from $GOPATH) After making sure my project was moved/symlinked into GOPATH, I had no trouble outside of a small warning: go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src; ignoring ../../../go.mod; see 'go help modules' Fetching https://gopkg.in/mail.v2?go-get=1 Parsing meta tags from https://gopkg.in/mail.v2?go-get=1 (status code 200) get "gopkg.in/mail.v2": found meta tag get.metaImport{Prefix:"gopkg.in/mail.v2", VCS:"git", RepoRoot:"https://gopkg.in/mail.v2"} at https://gopkg.in/mail.v2?go-get=1 gopkg.in/mail.v2 (download) gopkg.in/mail.v2 test Is this the same case for you too? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[markbates]

I’ve been working closely with members of the Go team on improving modules support, and I’ve brought this ticket to their attention as an experience report. Hopefully it’ll help them with docs and improvement s