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

cmd/go: versions are not picked up from Gopkg.lock in a dependency #26418

Closed
misha-ridge opened this issue Jul 17, 2018 · 6 comments
Closed

cmd/go: versions are not picked up from Gopkg.lock in a dependency #26418

misha-ridge opened this issue Jul 17, 2018 · 6 comments
Labels
FrozenDueToAge modules
Milestone
Go1.11

Comments

@misha-ridge
Copy link

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

go version go1.10.3 darwin/amd64 vgo:2018-02-20.1, vgo commit 0f3e556044ecbd8a0805d098e52a743a1d0e3566.

Also tested on go version devel +b59b42cee8 Tue Jul 17 10:07:18 2018 +0000 darwin/amd64

Does this issue reproduce with the latest release?

It used to work with vgo commit 0f3e556044ecbd8a0805d098e52a743a1d0e3566. I have bisected the breakage. Broke in 1b96834c2946460ab74b529df6b753fc0a03f628.

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dottedmag/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dottedmag/g"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.10.3/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.10.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mt/1tmwnxv96cg2vl1nz74_c9cm0000gn/T/go-build760675113=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package A go.mod:

require packageB v0.1.0

package B Gopkg.lock:

[[projects]]
...
  name = "packageC"
  version = "v0.1.0"
...

Old version of vgo honored the request for packageC v0.1.0. New versions of vgo and go from master ignore it and use latest one.

Minimal reproducer: https://github.com/misha-holahq/test-vgo-importer

What did you expect to see?

go run main.go
go: downloading github.com/misha-holahq/test-vgo-dep v0.1.0
2018/07/17 18:03:57 Running stuff

What did you see instead?

go run main.go
go: finding github.com/misha-holahq/test-vgo-dep v0.2.0
go: downloading github.com/misha-holahq/test-vgo-dep v0.2.0
# github.com/misha-holahq/test-vgo-importee
../../../go/src/mod/github.com/misha-holahq/test-vgo-importee@v0.1.0/lib.go:5:2: undefined: testvgodep.Run
@oiooj oiooj added the modules label Jul 17, 2018
@oiooj oiooj added this to the Go1.11 milestone Jul 17, 2018
@oiooj
Copy link
Member

oiooj commented Jul 17, 2018 •
edited

Go modules only handles package A's legacy config (Gopkg.lock) now.

@misha-ridge
Copy link
Author

So, what's the way to consume packages that are not go.mod-ified? By manually putting all the versions in replace directives in go.mod of packageA?

@misha-ridge
Copy link
Author

Could you please also clarify "will / now": does it mean "we decided it's the right thing to do, so it's not likely to change" or "we don't have resources to make it work for transitive packages in time for 1.11, so that's how it is going to work in the release, but probably going to be changed later"?

@oiooj
Copy link
Member

oiooj commented Jul 17, 2018 •
edited

@misha-holahq Sorry for my poor English. Fixed. From rsc's commit message:

if A requires B, both have Gopkg.lock but not go.mod, and we're
working in the repo for A, then it's fine to use A/Gopkg.lock to
create an initial A/go.mod. If there are problems with the A/go.mod,
we can edit that file to fix them. It's not fine to use B/Gopkg.lock
to create an effective B/go.mod for use during the build.
If there are any problems with the conversion in B, there is no
way for us (working on A) to override it.

https://go-review.googlesource.com/c/vgo/+/120999

I hope I can help you.

@bcmills
Copy link
Contributor

bcmills commented Jul 17, 2018

It's strange to have a go.mod checked in that isn't sufficient to build the project.

Note that once you have it set up, go mod -sync preserves the needed indirect dependencies:

$ export GO111MODULE=on
$ export GOPATH=$(pwd)
$ git clone https://github.com/misha-holahq/test-vgo-importer.git
Cloning into 'test-vgo-importer'...
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.

$ cd test-vgo-importer/
test-vgo-importer$ go build ./...
go: finding github.com/misha-holahq/test-vgo-importee v0.1.0
go: downloading github.com/misha-holahq/test-vgo-importee v0.1.0
go: finding github.com/misha-holahq/test-vgo-dep v0.2.0
go: downloading github.com/misha-holahq/test-vgo-dep v0.2.0
# github.com/misha-holahq/test-vgo-importee
../src/mod/github.com/misha-holahq/test-vgo-importee@v0.1.0/lib.go:5:2: undefined: testvgodep.Run

test-vgo-importer$ go get github.com/misha-holahq/test-vgo-dep@v0.1.0
go: finding github.com/misha-holahq/test-vgo-dep v0.1.0
go: downloading github.com/misha-holahq/test-vgo-dep v0.1.0

test-vgo-importer$ go build ./...
test-vgo-importer$ go mod -sync
test-vgo-importer$ cat go.mod
module github.com/misha-holahq/test-vgo-importer

require (
        github.com/misha-holahq/test-vgo-dep v0.1.0 // indirect
        github.com/misha-holahq/test-vgo-importee v0.1.0
)

test-vgo-importer$ go build ./...
test-vgo-importer$

@bcmills
Copy link
Contributor

bcmills commented Jul 17, 2018

So, what's the way to consume packages that are not go.mod-ified? By manually putting all the versions in replace directives in go.mod of packageA?

Add the missing dependencies to the go.mod for the top-level project, with an // indirect comment (which go get will add automatically if you use that).

As far as I can tell, // indirect dependencies work as intended for your example module, but please reopen if you find that they don't.

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

No branches or pull requests
4 participants
@oiooj @bcmills @gopherbot @misha-ridge