Indirect dependency github.com/blend/go-sdk v1.1.1 does not exist

[stevebriskin]

I suspect that the library maintainers prepended "legacy-" to versions before changing the versioning scheme. At the least, this dependency should be updated to legacy-v1.1.1.

[pjebs]

If it's indirect, how can I control it?

[stevebriskin]

You can explicitly set it in your go.mod file to override “v1.1.1” to “legacy-v1.1.1”. Or determine which of your dependence’s pulls it in with ‘go mod graph’ and upgrade that one.

…

On Jul 1, 2022, at 6:27 PM, pj ***@***.***> wrote:  If it's indirect, how can I control it? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[MarkieMark]

to clarify what Steve said, adding

replace (
	github.com/blend/go-sdk v1.1.1 => github.com/blend/go-sdk legacy-v1.1.1
)

to your go.mod works; however there is now a new dependency error

go: github.com/sjwhitworth/[email protected] requires
	github.com/rocketlaunchr/[email protected] requires
	github.com/cnkei/[email protected]: invalid version: unknown revision 842a72f86331

that needs a more involved replace directive

github.com/cnkei/gospline v0.0.0-20191204072713-842a72f86331 => github.com/cnkei/gospline v0.0.0-20191204052713-d67fac29a294

[pjebs]

I've never been able to reproduce this issue. That's why this issue has been kept open.

[MarkieMark]

I'm working in Fedora 36 with (as far as I recall) a basically vanilla .rpm go; a $ go get github.com/sjwhitworth/golearn from a Fedora 36 virtual machine should behave similarly

[stevebriskin]

We encountered it after configuring our project for dependabot in github. Dependabot runs failed fetching blend.
Our theory is that go get uses a proxy by default which caches blend v1.1.1 even though the tag has been renamed to legacy-v1.1.1. To repro, we ran go get without a proxy GONOSUMDB=* GONOPROXY=* go get -x github.com/blend/[email protected] which led to "unknown revision" errors. So... things currently work but presumably only because there's a proxy that caches this old tag, which is flaky.

Per https://proxy.golang.org/:

Whenever possible, the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository.