v1.7.10 requires a module by the wrong version

[FiloSottile]

github.com/influxdata/influxdb@v1.7.10 requires github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c. Commit google/go-github@dd29b543e14c shows a go.mod with path github.com/google/go-github/v18 so it can't be used with v0.0.0 and naked github.com/google/go-github import path.

Go 1.13 notices and breaks.

go: github.com/influxdata/influxdb@v1.7.10 requires
	github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c: invalid version: go.mod has post-v0 module path "github.com/google/go-github/v18" at revision dd29b543e14c

In other words, github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c doesn't exist, that commit is github.com/google/go-github/v18@v18.2.1-0.20181009003523-dd29b543e14c.

[mark-rushakoff]

Thanks for the report @FiloSottile.

@e-dard introduced go.mod in into the 1.7 branch in cbae66e, via #15863 -- there was no mention of go.mod in the commit message or in the PR comments by reviewers @jacobmarble nor @benbjohnson.

I noticed we also still have Gopkg.lock. My suspicion is that we weren't intending to migrate to modules for influxdb 1.7 yet. But now that we've published 1.7.10 with modules, it seems like we ought to fix up go.mod in 1.7.11.

I did try deleting github.com/google/go-github v0.0.0-20181009003523-dd29b543e14c line from go.mod and then running go get github.com/google/go-github/v18@dd29b543e14c, but that ran into the next error: go: gopkg.in/russross/blackfriday.v2@v2.0.1: go.mod has non-....v2 module path "github.com/russross/blackfriday/v2" at revision v2.0.1.

Then, deleting the gopkg.in/russross/blackfriday.v2 v2.0.1 line from go.mod allows go get github.com/google/go-github/v18@dd29b543e14c to run successfully, but it also updates many of the referenced modules' versions.

@dgnorton let's see if we can get modules set up properly for 1.7.11.

[FiloSottile]

Looks like the go.mod was created with go mod init which printed errors about those v2 modules, but they were not fixed.

The reason it looks like it's updating stuff when you run it is that go mod tidy will report in your go.mod the version that's actually being used based on the dependency graph.

For example, you require github.com/cespare/xxhash@v1.0.0, but also github.com/influxdata/flux@v0.50.2 which requires github.com/cespare/xxhash@v1.1.0, so go mod tidy just reports it correctly.

$ go mod graph
github.com/influxdata/influxdb github.com/influxdata/flux@v0.50.2
github.com/influxdata/flux@v0.50.2 github.com/cespare/xxhash@v1.1.0

[FiloSottile]

I prepared a cleaned up go.mod with no updates (beyond the ones forced by transitive dependencies) in #16903. I imagine it will not be enough as a PR, so feel free to just take the go.mod from it.

[russorat]

this is causing builds to fail on homebrew: Homebrew/homebrew-core#49900

[veorlo]

This is causing a downstream issue where the compilation of external plugins written in golang for influxdata/telegraf will fail with the exact same error.

[korjavin]

I'm sorry. I didn't get. How should I fix this?

[dcormier]

@korjavin, add this to your go.mod file:

// TODO: Keep this until this is fixed and released (>1.7.10):
// https://github.com/influxdata/influxdb/issues/16901
replace github.com/influxdata/influxdb => github.com/influxdata/influxdb v1.7.9

[mvdan]

I'm still hitting this in 2021. Having to use a replace directive is a bit sad. I could upgrade to v1.8 or later, but the dependency is indirect, and I'd rather not risk breaking my dependencies.

I could avoid this by only upgrading to v1.7.9, but that's not particularly easy to do unless v1.7.10 is retracted as a broken version. For example, go get -d -u=patch ./... is a reasonable thing to do, but it will attempt to use v1.7.10 and fail.

[davidby-influx]

Fixed with the release of 1.7.11