Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/vgo: vgo unable to find go.mod file of package in tagged GitHub repo #25494

Closed
vladimiroff opened this issue May 22, 2018 · 9 comments
Closed

x/vgo: vgo unable to find go.mod file of package in tagged GitHub repo #25494

vladimiroff opened this issue May 22, 2018 · 9 comments
Labels
FrozenDueToAge
Milestone
vgo

Comments

@vladimiroff
Copy link

Please answer these questions before submitting your issue. Thanks!

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

go version go1.10.2 linux/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?

Yes, even with just updated vgo (go get -u golang.org/x/vgo)

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kiril/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/kiril/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/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-build218058509=/tmp/go-build -gno-record-gcc-switches"
VGOMODROOT=""

What did you do?

  1. Forked github.com/pressly/goose in order to add go.mod file (there's a v2 version already)
  2. In order to test my changes, in master branch I've renamed the package in master, created go.mod file with /v2 suffix of the module name and tagged the release as v2.3.2
  3. Created a test project importing the new release:
mkdir $GOPATH/src/github.com/vladimiroff/foo
cd $GOPATH/src/github.com/vladimiroff/foo
  1. Created dummy foo.go just to import forked version of goose:
package foo // import "github.com/vladimiroff/foo"
import goose "github.com/vladimiroff/goose/v2"

var MaxVersion = goose.MaxVersion

func Foo() goose.SQLDialect {
        return goose.GetDialect()
}
  1. Created go.mod file as well:
module github.com/vladimiroff/foo

require github.com/vladimiroff/goose/v2 v2.3.2

What did you expect to see?

vgo build to succeed.

What did you see instead?

--> vgo build
vgo: finding github.com/vladimiroff/goose/v2 v2.3.2
vgo: github.com/vladimiroff/goose/v2 v2.3.2: missing go.mod
vgo: finding github.com/vladimiroff/goose/v2 v2.3.2
vgo: github.com/vladimiroff/goose/v2 v2.3.2: missing go.mod

There's obviously a go.mod file in there: https://github.com/vladimiroff/goose/blob/v2.3.2/go.mod

vgo build succeeds only after replacing github.com/vladimiroff/goose/v2 with local version of the package in go.mod:

module github.com/vladimiroff/foo

replace github.com/vladimiroff/goose/v2 v2.3.2 => ../goose
require github.com/vladimiroff/goose/v2 v2.3.2
@gopherbot gopherbot added this to the vgo milestone May 22, 2018
@vladimiroff vladimiroff mentioned this issue May 22, 2018
Closed
@rogpeppe
Copy link
Contributor

I'll add to this. When I tried a "vgo get -u" with that goose repo, I saw this panic:

% vgo get -u
vgo: finding gopkg.in/check.v1 latest
vgo: finding gopkg.in/yaml.v2 latest
vgo: finding gopkg.in/check.v1 latest
vgo: resolving import "github.com/vladimiroff/goose/v2"
vgo: finding github.com/vladimiroff/goose (latest)
vgo: adding github.com/vladimiroff/goose v0.0.0-20180522081621-7b08ab39b54e
vgo: finding gopkg.in/check.v1 latest
vgo: finding gopkg.in/yaml.v2 latest
vgo: finding github.com/vladimiroff/goose latest
vgo: finding gopkg.in/check.v1 latest
vgo: finding github.com/vladimiroff/goose v0.0.0-20180522081621-7b08ab39b54e
panic: downloaded "github.com/vladimiroff/goose" and got module "github.com/vladimiroff/goose/v2"

goroutine 1 [running]:
golang.org/x/vgo/vendor/cmd/go/internal/mvs.UpgradeAll(0xc0001f0200, 0x1b, 0x0, 0x0, 0x98c0e0, 0xc00022aa60, 0xc0000aac00, 0x3, 0x4, 0x0, ...)
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/internal/mvs/mvs.go:174 +0x62c
golang.org/x/vgo/vendor/cmd/go/internal/vgo.iterate(0xc0001d9a78)
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/internal/vgo/load.go:140 +0x210
golang.org/x/vgo/vendor/cmd/go/internal/vgo.importPaths(0xc0002d4280, 0x1, 0x1, 0xd0, 0x8d2760, 0x30)
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/internal/vgo/load.go:83 +0xde
golang.org/x/vgo/vendor/cmd/go/internal/vgo.ImportPaths(0xc0001d9c50, 0x1, 0x1, 0x0, 0x8b5148, 0x30)
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/internal/vgo/load.go:71 +0x58
golang.org/x/vgo/vendor/cmd/go/internal/vgo.runGet(0xbb5be0, 0xc00001e0b0, 0x0, 0x0)
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/internal/vgo/get.go:54 +0xebb
golang.org/x/vgo/vendor/cmd/go.Main()
	/home/rog/src/go/src/golang.org/x/vgo/vendor/cmd/go/main.go:155 +0x7a9
main.main()
	/home/rog/src/go/src/golang.org/x/vgo/main.go:31 +0x20

When I tried again from scratch, I couldn't reproduce this, but perhaps the panic is enough in itself.

@kardianos
Copy link
Contributor

There is an issue resolving the module path from the go.mod file in vgo/vendor/cmd/go/internal/modfetch/coderepo.go Line 246 in func modPath. We should add some unit tests to this package to test this function and make it more robust.

CL coming up.

@gopherbot
Copy link

Change https://golang.org/cl/114005 mentions this issue: cmd/go/internal/modfetch: use modfile when finding module path

@kardianos
Copy link
Contributor

@rogpeppe I was unable to reproduce your panic either :/

@vladimiroff The attached CL fixes the issue you experienced. Feel free to confirm.

@kardianos
Copy link
Contributor

Change https://golang.org/cl/114058 also fixes this issue. I just saw it when I pushed to Gerrit and saw the merge conflicts. I think parts of both CLs could be useful to get in.

@AlexRouSg
Copy link
Contributor

AlexRouSg commented May 22, 2018 •
edited

@kardianos A reliable way to get the panic is to have a empty (other than the module declaration) go.mod file and vgo build. (where the package imports github.com/vladimiroff/goose/v2)

@kardianos
Copy link
Contributor

Huh. It doesn't do that anymore with the linked CL.

@AlexRouSg
Copy link
Contributor

ohh nvm then, didn't tried the CL

@AlexRouSg AlexRouSg mentioned this issue May 23, 2018
Closed
@bcmills
Copy link
Contributor

bcmills commented Jun 29, 2018

This seems to be fixed at head. (Following your steps to reproduce, vgo build succeeded for me.)

Please reopen if you're still able to reproduce the problem.

@bcmills bcmills closed this as completed Jun 29, 2018
@golang golang locked and limited conversation to collaborators Jun 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
vgo
Development

No branches or pull requests
6 participants
@rogpeppe @vladimiroff @kardianos @bcmills @AlexRouSg @gopherbot