cmd/go: disabling go.mod conversion for transitive deps breaks echo example?

[myitcv]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.10.3 linux/amd64
vgo commit cd1f2ee17589ba3f7f17471441f18612f864e850

Does this issue reproduce with the latest release?

Yes and the listed vgo commit

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/vgo-by-example/.gopath"
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build020462338=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This might be an intentional change as part of https://go-review.googlesource.com/120999, but I haven't had a chance to investigate further I'm afraid.

$ go get -u golang.org/x/vgo
$ cd /root/src/golang.org/x/vgo
$ git checkout cd1f2ee17589ba3f7f17471441f18612f864e850
$ go install
$ mkdir hello
$ cd hello
$ cat <<EOD >main.go
package main // import "example.com/hello"

import (
        "net/http"

        "github.com/labstack/echo"
        "github.com/labstack/echo/middleware"
)

func main() {
        // Echo instance
        e := echo.New()

        // Middleware
        e.Use(middleware.Logger())
        e.Use(middleware.Recover())

        // Routes
        e.GET("/", hello)

        // Start server
        e.Logger.Fatal(e.Start(":1323"))
}

// Handler
func hello(c echo.Context) error {
        return c.String(http.StatusOK, "Hello, World!")
}
EOD
$ echo >go.mod
$ vgo get github.com/labstack/[email protected]
vgo: finding github.com/labstack/echo v3.2.1
vgo: downloading github.com/labstack/echo v0.0.0-20170621150743-935a60782cbb
vgo: resolving import "github.com/labstack/gommon/color"
vgo: finding github.com/labstack/gommon/color latest
vgo: finding github.com/labstack/gommon v0.2.1
vgo: finding github.com/labstack/gommon (latest)
vgo: adding github.com/labstack/gommon v0.2.1
vgo: resolving import "golang.org/x/crypto/acme/autocert"
vgo: finding golang.org/x/crypto/acme/autocert latest
vgo: finding golang.org/x/crypto/acme latest
vgo: finding golang.org/x/crypto latest
vgo: finding golang.org/x/crypto (latest)
vgo: adding golang.org/x/crypto v0.0.0-20180621125126-a49355c7e3f8
vgo: downloading github.com/labstack/gommon v0.2.1
vgo: downloading golang.org/x/crypto v0.0.0-20180621125126-a49355c7e3f8
vgo: resolving import "github.com/mattn/go-colorable"
vgo: finding github.com/mattn/go-colorable v0.0.9
vgo: finding github.com/mattn/go-colorable (latest)
vgo: adding github.com/mattn/go-colorable v0.0.9
vgo: resolving import "github.com/mattn/go-isatty"
vgo: finding github.com/mattn/go-isatty v0.0.3
vgo: finding github.com/mattn/go-isatty (latest)
vgo: adding github.com/mattn/go-isatty v0.0.3
vgo: resolving import "github.com/valyala/fasttemplate"
vgo: finding github.com/valyala/fasttemplate latest
vgo: finding github.com/valyala/fasttemplate (latest)
vgo: adding github.com/valyala/fasttemplate v0.0.0-20170224212429-dcecefd839c4
vgo: downloading github.com/mattn/go-colorable v0.0.9
vgo: downloading github.com/mattn/go-isatty v0.0.3
vgo: downloading github.com/valyala/fasttemplate v0.0.0-20170224212429-dcecefd839c4
vgo: resolving import "github.com/valyala/bytebufferpool"
vgo: finding github.com/valyala/bytebufferpool latest
vgo: finding github.com/valyala/bytebufferpool (latest)
vgo: adding github.com/valyala/bytebufferpool v0.0.0-20160817181652-e746df99fe4a
vgo: downloading github.com/valyala/bytebufferpool v0.0.0-20160817181652-e746df99fe4a
$ vgo build

What did you expect to see?

A successful build.

What did you see instead?

vgo: resolving import "github.com/dgrijalva/jwt-go"
vgo: finding github.com/dgrijalva/jwt-go v1.0.2
vgo: finding github.com/dgrijalva/jwt-go (latest)
vgo: adding github.com/dgrijalva/jwt-go v1.0.2
vgo: downloading github.com/dgrijalva/jwt-go v1.0.2
vgo: finding github.com/labstack/echo v0.0.0-20170621150743-935a60782cbb
# github.com/labstack/echo/middleware
/root/src/mod/github.com/labstack/[email protected]/middleware/jwt.go:34:10: undefined: jwt.Claims

Compare to the previous commit (06e664301cec279012e90c60689c5ad4e11fd3f1):

$ vgo get github.com/labstack/[email protected]
vgo: finding github.com/labstack/echo v3.2.1
vgo: downloading github.com/labstack/echo v0.0.0-20170621150743-935a60782cbb
vgo: downloading github.com/labstack/gommon v0.2.1
vgo: downloading github.com/mattn/go-colorable v0.0.7
vgo: downloading github.com/mattn/go-isatty v0.0.2
vgo: downloading github.com/valyala/fasttemplate v0.0.0-20170224212429-dcecefd839c4
vgo: downloading github.com/valyala/bytebufferpool v0.0.0-20160817181652-e746df99fe4a
vgo: downloading golang.org/x/crypto v0.0.0-20170601173114-e1a4589e7d3e
vgo: finding github.com/mattn/go-colorable v0.0.7
vgo: finding github.com/mattn/go-isatty v0.0.2
vgo: finding github.com/labstack/gommon v0.2.1
vgo: finding github.com/valyala/bytebufferpool v0.0.0-20160817181652-e746df99fe4a
vgo: finding github.com/valyala/fasttemplate v0.0.0-20170224212429-dcecefd839c4
vgo: finding golang.org/x/crypto v0.0.0-20170601173114-e1a4589e7d3e
$ vgo build
vgo: downloading github.com/dgrijalva/jwt-go v0.0.0-20160616191556-d2709f9f1f31
vgo: finding github.com/labstack/echo v0.0.0-20170621150743-935a60782cbb
vgo: finding github.com/dgrijalva/jwt-go v0.0.0-20160616191556-d2709f9f1f31

/cc @rsc @bcmills

[bcmills]

We don't want the generated go.mod for the packages you import to specify anything, because you have no way to fix it if it's wrong.

On the other hand, if we're generating a new go.mod for a brand new module, and it imports a bunch of packages that have legacy lock files, we probably shouldn't synthesize a go.mod that requires versions older than what's in those lock files.

I think the root of the problem is the interaction between version tags, go.mod files, and pseudo-versions. Today, we do not treat a v2.0.0 tag as a semantic version unless it matches the import path: we resolve the tag to a commit and then store than commit as a pseudoversion, and treat all pseudoversions as older than all semantic versions. That sorts a pre-vgo v1.0.0 tag above a pre-vgo v2.0.0 tag.

Perhaps we should not treat a pre-vgo v1.0.0 as a valid semantic version either. Then, instead of picking github.com/dgrijalva/jwt-go v1.0.2 as the “latest” version, we would instead pick either v3.2.0 (the latest tag) or 06ea103 (the latest commit as of this comment), and existing packages would be more likely to build.

[bcmills]

(This is related to the issues addressed in https://golang.org/cl/121000, but if I understand that change correctly, it will not address this issue.)

[bcmills]

I think the root of the problem is the interaction between version tags, go.mod files, and pseudo-versions.

That's #26238. Should we close this as a duplicate of that?

[myitcv]

Should we close this as a duplicate of that?

Yes, sounds good.