search

rocketlaunchr / dataframe-go

DataFrames for Go: For statistics, machine-learning, and data manipulation/exploration
Other
1.19k stars 95 forks source link

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

Open stevebriskin opened 2 years ago

stevebriskin commented 2 years ago

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 commented 2 years ago

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

stevebriskin commented 2 years ago

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 commented 2 years ago

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/golearn@v0.0.0-20211014193759-a8b69c276cd8 requires
    github.com/rocketlaunchr/dataframe-go@v0.0.0-20201007021539-67b046771f0b requires
    github.com/cnkei/gospline@v0.0.0-20191204072713-842a72f86331: 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 commented 2 years ago

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

MarkieMark commented 2 years ago

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 commented 2 years ago

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/go-sdk@v1.1.1 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.