go-sqlite3: Problem with unstable go-sqlite3 version - 2.0.3
Hi,
We at the platform team of razorpay internally use bulk-insert which internally uses github.com/jinzhu/gorm v1.9.12 and creates an indirect dependency on github.com/mattn/go-sqlite3 v2.0.3.
Reference :- https://github.com/t-tiger/gorm-bulk-insert/blob/master/go.mod#L14
Now, this setup was working fine for us till last week and suddenly we had a failure in our docker build for github actions citing
github.com/mattn/go-sqlite3@v2.0.3+incompatible: unknown revision v2.0.3
We also saw one of your issues where you mentioned versions 2.0+ were unstable - issue
Did you stop supporting 2.0.3 version suddenly in the last 7-10 days. We were wondering what caused the breakage of the build from our side. It would be helpful if you could throw some light on this issue.
Thanks, Shriram
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 5
- Comments: 40 (14 by maintainers)
Commits related to this issue
- go.mod: update github.com/containers/image/v5 Version 5.22 introduced a new option to /etc/containers/policy.json called keyPaths, see https://github.com/containers/image/pull/1609 EL9 immediately ... — committed to ondrejbudai/osbuild-composer by ondrejbudai 2 years ago
- go.mod: update github.com/containers/image/v5 Version 5.22 introduced a new option to /etc/containers/policy.json called keyPaths, see https://github.com/containers/image/pull/1609 EL9 immediately ... — committed to ondrejbudai/osbuild-composer by ondrejbudai 2 years ago
- go.mod: update github.com/containers/image/v5 Version 5.22 introduced a new option to /etc/containers/policy.json called keyPaths, see https://github.com/containers/image/pull/1609 EL9 immediately ... — committed to osbuild/osbuild-composer by ondrejbudai 2 years ago
I got the same problem but after I did
go env -w GOPROXY="https://proxy.golang.org,direct"now it can download.That’s not the case. People will be stumbling onto this for a while.
go-sqlite3is a very wide spread dependency and gets added into other projects during both manual and automated tasks.Commits like this and this are actively referenced in projects today.
There are 39,000 files that come up with I search to get an idea of how wide spread this is.
Indeed, I can update my code, but there are tons of 3rd party libs which require go-sqlite v2.x.x Should I fork them all ?
@mattn Even though you retracted those versions, those tags should never be deleted, so that people can continue to download their dependencies, including for older versions of their projects.
This issue is already reported to Go team. https://github.com/golang/go/issues/35732
But those tags were already released. So there are other libraries and projects that reference them. By deleting them, those versions cannot be built properly anymore (without using a Go module proxy), which was the original stated issue. We can tell people not to use v2 in new versions of their code anymore, but we should not cause the older/existing versions to break.
One way to fix this is adding the below code to the go.mod file
exclude github.com/mattn/go-sqlite3 v2.0.3+incompatible