fix(cmd): build with local v1 and v2 mods

[davidebeatrici]

No description provided.

[rvagg]

Tagging was intentional here, slightly annoying, but on purpose. Using a replace is (IIRC) going to break go install from the proxy, it complicates our dual-tagging release process in here (we tag both 0.x and 2.x from master), and I think it might screw with the GoReleaser build process too. go-car/cmd is a separate package and bundled separately and doesn't suffer from untagged-version drift in the current design. It does have tradeoffs though, one of the main ones being that tags take a whole release cycle + dependabot + another tag to get updated in cmd unless we're intentional, it would be nice if that were streamlined a little more, but I don't think replace directives are the way to achieve this.

We could add a go.work though which I think might solve some dev pain-points here?

go 1.24
use (
    .
    ./v2
    ./cmd
)

I'd be happy to merge a PR with that I think.

[davidebeatrici]

For context: while packaging this for OpenMandriva (https://github.com/OpenMandrivaAssociation/car) I realized the v1 and v2 mods were being pulled in as external dependencies because cmd's project is not aware of their existence in the local repository.

The workflow goes like this:

1. Fetch source and run go mod vendor into it.
2. Store the vendor folder.
3. Perform a fully offline build by running go build -mod=vendor.

Thank you for the explanation regarding the dual-tagging design. Maybe it would make sense to split this into separate repositories, considering the modules may be used by external projects?

[rvagg]

OK, that sounds like a bit of friction. But multi-module Go repos are pretty standard, and the Go tooling treats them as separate, so when you go install github.com/ipld/go-car/cmd then it expects that cmd is an entirely separate thing, it just happens to share a version control root. Lots of Go tooling deals with modules like this. So it ends up being a great convenience for development, testing and cross-module integration, not too dissimilar to Rust workspaces, or npm/pnpm workspaces for monorepos, but the tooling is even more clever.

Perhaps the distro build script could just copy the local ./ and ./v2 directories into the vendor tree at the right module paths instead of relying on go mod vendor alone? That might reduce the friction a little?

[davidebeatrici]

To be fair, our main concern is ensuring everything is built from source (bar a few exceptions, such as firmware blobs).

I just checked and it looks like with Go modules are never brought in as a binary but always as a source, which is really nice.

We can indeed copy the local mods into the vendor tree, but at this point it's not a problem since go mod vendor brings all dependencies in.

I don't have much experience with Go, so please correct me if I'm wrong.

[rvagg]

That all sounds good to me, and I think the original concern here might be resolved? Correct me if I'm wrong but I'll close this for now.

[davidebeatrici]

It's indeed solved, thank you again!