Skip to content

deps(duckdb): keep go-store on a single, current duckdb binding #6

Description

@Snider

Status

go/v0.14.0 (commit 4629c48) moved go-store's duckdb driver from github.com/marcboeker/go-duckdb (v1.8.5) → github.com/marcboeker/go-duckdb/v2 (v2.4.3). This unifies the ecosystem on one duckdb binding so downstream binaries (go-inference's lem) link without duplicate-symbol errors.

Why it kept getting reverted (so it doesn't happen a 4th time)

The v1→v2 bump was done before (commit 37ed852) but a later go mod tidy silently reverted it every time: the blank-import in go/duckdb_driver.go stayed on the v1 module path, so tidy re-selected v1 and stripped the v2 binding lines. The durable fix moves the code import to /v2 — now tidy keeps v2.

Guard: duckdb version work must change the import path in go/duckdb_driver.go, never just go.mod. A go.mod-only bump will be reverted by the next tidy.

Forward work (why this issue stays open)

go get now warns:

github.com/marcboeker/go-duckdb/v2 is deprecated: This module has moved to github.com/duckdb/duckdb-go

The next update is v2 → github.com/duckdb/duckdb-go. Same guard: change the import path, confirm go mod tidy keeps it, verify the driver still registers under database/sql ("duckdb"), and that the cgo build links a single duckdb lib.

Related

  • go-io ships its own duckdb store (go-io/store) still on v1.8.5. Not linked by go-inference (graph-only), but should follow the same migration for consistency.

Metadata

Metadata

Assignees

No one assigned

    Labels

    depsDependency currency / version bumps

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions