Dep: Using dep with a project depending on "gomail" results in unbuildable package

[dcelasun]

Repro steps

See minimal repro here.

Description

The problem is dep resolves gopkg.in/gomail.v2 to an ancient commit (#41f3572), which doesn't have the NewDialer function. go get, however, does the right thing with go get gopkg.in/gomail.v2.

What version of Go (go version) and dep (git describe --tags) are you using?

$ go version
go version go1.8.3 linux/amd64
$ git describe --tags
v0.1.0-175-gc79b048

What dep command did you run?

2 dep commands and then go build:

$ dep init -v
Root project is "github.com/dcelasun/depbug"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)     ? attempt gopkg.in/gomail.v2 with 1 pkgs; 2 versions to try
(1)         try gopkg.in/[email protected]
(1)     ✓ select gopkg.in/[email protected] w/1 pkgs
(2)     ? attempt gopkg.in/alexcesaro/quotedprintable.v3 with 1 pkgs; 1 versions to try
(2)         try gopkg.in/alexcesaro/quotedprintable.v3@v3
(2)     ✓ select gopkg.in/alexcesaro/quotedprintable.v3@v3 w/1 pkgs
  ✓ found solution with 2 packages from 2 projects

Solver wall times by segment:
     b-source-exists: 1.047797051s
              b-gmal: 605.276162ms
         b-list-pkgs:  80.911028ms
             satisfy:    215.007µs
         select-atom:    108.945µs
  b-deduce-proj-root:     54.451µs
            new-atom:     54.309µs
         select-root:     34.937µs
     b-list-versions:     10.832µs
               other:      8.684µs

  TOTAL: 1.734471406s

  Using ^2.0.0 as constraint for direct dep gopkg.in/gomail.v2
  Locking in 2.0.0 (41f3572) for direct dep gopkg.in/gomail.v2
  Locking in v3 (2caba25) for transitive dep gopkg.in/alexcesaro/quotedprintable.v3

$ dep ensure -update -v
Root project is "github.com/dcelasun/depbug"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)     ? attempt gopkg.in/gomail.v2 with 1 pkgs; 2 versions to try
(1)         try gopkg.in/[email protected]
(1)     ✓ select gopkg.in/[email protected] w/1 pkgs
(2)     ? attempt gopkg.in/alexcesaro/quotedprintable.v3 with 1 pkgs; 1 versions to try
(2)         try gopkg.in/alexcesaro/quotedprintable.v3@v3
(2)     ✓ select gopkg.in/alexcesaro/quotedprintable.v3@v3 w/1 pkgs
  ✓ found solution with 2 packages from 2 projects

Solver wall times by segment:
     b-source-exists: 976.934541ms
         b-list-pkgs: 663.228151ms
              b-gmal:  83.486936ms
            new-atom:    100.612µs
             satisfy:     77.566µs
         select-atom:     68.636µs
         select-root:     42.832µs
     b-list-versions:     11.982µs
               other:      7.424µs
  b-deduce-proj-root:      2.138µs

  TOTAL: 1.723960818s

Finally go build.

What did you expect to see?

$ go build

What did you see instead?

$ go build
# github.com/dcelasun/depbug
./main.go:8: undefined: gomail.NewDialer

[ibrasho]

Hello @dcelasun.

Semver tags are preferred to branches. gopkg.in/gomail.v2 has a tag 2.0.0 and that is the version dep selects in this case. This answer in the FAQs should help you understand how dep selects versions.

The solution is to update the constraints in Gopkg.toml to use branch instead of version:

[[constraint]]
  name = "gopkg.in/gomail.v2"
  branch = "v2"

instead of:

[[constraint]]
  name = "gopkg.in/gomail.v2"
  version = "2.0.0"

and then make sure to run dep ensure.

[carolynvs]

I think this is the same init problem that #715 is attempting to fix by having init detect the v2 branch and uses it instead of the semver.

[dcelasun]

It definitely looks related, but #715 only applies to configs imported from other tools, right? The question is how it should behave when the only information available is the import path. I don't think there is a solution that'll satisfy every use case :/

[carolynvs]

Yeah they are not exact same problem but are quite similar. In this case, dep isn't following gopkg.in's sorting rules, where a branch named v2 is less than a tag named v2.0.0, and therefore is preferred when deciding what "gopkg.in/foo.v2" should resolve to.

[carolynvs]

I'm going to work on this (and #776) as they are both related to how we sort/resolve gopkg.in versions.

[ibrasho]

@carolynvs Do we have anything documented on how we handle gopkg.in packages?

It seems like it doesn't (or at least should not) follow the same rules as other sources, probably because gopkg.in URLs hold version information...

[carolynvs]

There's no doc that I'm aware of. I am basing my understanding of things on the source code for dep https://github.com/golang/dep/blob/master/internal/gps/vcs_source.go#L285 and gopkg https://github.com/niemeyer/gopkg/blob/master/version.go#L9.

In my opinion, during init dep should follow the same version matching rules that gopkg uses when parsing a gopkg URL.

[sdboyer]

Confirming @carolynvs' answer to your question, @ibrasho - i wrote the gopkg.in implementation quite some time ago, but never did document it anywhere.

We should probably create a documentation area specifically for how import path deduction works. Analogous to the go docs on remote import paths, but necessarily more detailed.

[mariaefi29]

Dear engineers,

Do I understand right that this is just the way it works and you are not going to fix it?

Your comments have helped a lot. I was bummed when I saw that mistake poped up after dep installation.

[carolynvs]

@mariaefi29 Thanks for asking about this. IMO it's a bug that needs to be fixed. I thought that I had traction on it earlier but turns out that I was wrong.