Skip to content

cmd/go: get -u pulls in unreferenced v2 version #32495

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.

Sign up for GitHub

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
Closed
bep opened this issue Jun 8, 2019 · 4 comments
Closed

cmd/go: get -u pulls in unreferenced v2 version #32495

bep opened this issue Jun 8, 2019 · 4 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@bep
Copy link
Contributor

bep commented Jun 8, 2019 •
edited
Loading

As popular Go modules tend to spread, I think this problem is widespread (people having problems doing go get -u on their Go projects) (see spf13/cobra#805 gohugoio/hugo#5954).

I have tried to understand what's going on, but I fail to understand it, so I suspect it's a bug in Go itself.

/cc @spf13

▶ git clone https://github.com/spf13/cobra.git
▶ cd cobra
▶ go mod graph | grep black
github.com/cpuguy83/go-md2man@v1.0.10 github.com/russross/blackfriday@v1.5.2                                                                                      

▶ go get -u
▶ go mod graph | grep black
github.com/spf13/cobra github.com/russross/blackfriday@v2.0.0+incompatible
github.com/cpuguy83/go-md2man@v1.0.10 github.com/russross/blackfriday@v1.5.2

My env:

▶ go version
go version go1.12.5 darwin/amd64

▶ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/bep/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bep/go"
GOPROXY="https://proxy.golang.org"
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/bep/dev/dump/cobra/go.mod"
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/n6/s_85mm8d31j6yctssnmn_g1r0000gn/T/go-build120146809=/tmp/go-build -gno-record-gcc-switches -fno-common"
@agnivade
Copy link
Contributor

agnivade commented Jun 8, 2019

What is the exact issue ? Is it that after running go mod graph again, you get a blackfriday@v2 ?

If that is so, I am unable to reproduce it. For me, it's always that one line of 1.5.2. I am on 1.12.4 though.

@bep
Copy link
Contributor Author

bep commented Jun 8, 2019

What is the exact issue ? Is it that after running go mod graph again, you get a blackfriday@v2 ?

Yes. I added a newline to my initial comment (seems GitHub hid the important "go get -u" step).

I just tried the above again, and now I get another (but related error), indicating that there is some cache thing going on:

# github.com/cpuguy83/go-md2man/md2man
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:11:16: undefined: blackfriday.EXTENSION_NO_INTRA_EMPHASIS
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:12:16: undefined: blackfriday.EXTENSION_TABLES
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:13:16: undefined: blackfriday.EXTENSION_FENCED_CODE
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:14:16: undefined: blackfriday.EXTENSION_AUTOLINK
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:15:16: undefined: blackfriday.EXTENSION_SPACE_HEADERS
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:16:16: undefined: blackfriday.EXTENSION_FOOTNOTES
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:17:16: undefined: blackfriday.EXTENSION_TITLEBLOCK
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/md2man.go:19:29: too many arguments to conversion to blackfriday.Markdown: blackfriday.Markdown(doc, renderer, extensions)
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/roff.go:19:9: cannot use &roffRenderer literal (type *roffRenderer) as type blackfriday.Renderer in return argument:
	*roffRenderer does not implement blackfriday.Renderer (missing RenderFooter method)
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/roff.go:102:11: undefined: blackfriday.LIST_TYPE_ORDERED
../../../go/pkg/mod/github.com/cpuguy83/go-md2man@v1.0.10/md2man/roff.go:102:11: too many errors

@agnivade agnivade changed the title modules: pulls in unreferenced v2 version cmd/go: get -u pulls in unreferenced v2 version Jun 8, 2019
@agnivade agnivade added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 8, 2019
@agnivade
Copy link
Contributor

agnivade commented Jun 8, 2019

@jayconrod @bcmills

@bcmills
Copy link
Contributor

bcmills commented Jun 10, 2019

go get -u intentionally upgrades the versions of dependencies.

blackfriday v2.0.0 predates the introduction of modules (as evidenced by its lack of go.mod file), so go get -u considers it to be a more recent version of the import path github.com/russross/blackfriday rather than github.com/russross/blackfriday/v2.

One of the invariants of Go modules is that each import path indicates one unique version of the package. So github.com/russross/blackfriday must resolve to one specific version, and which version is intended by which importer is not obvious from the source code alone: for example, we have no way of knowing whether you're running go get -u in order to write new code that depends on the v2.0.0 API.

Semantic import paths in module mode are specifically intended to address this problem, but unfortunately they don't help with dependencies that made breaking changes before the introduction of modules.

@bcmills bcmills closed this as completed Jun 10, 2019
@masci masci mentioned this issue Jul 17, 2019
Closed
@golang golang locked and limited conversation to collaborators Jun 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bep @agnivade @bcmills @gopherbot