Tooling to minimize impact on those updating to boxo

[BigLep]

Identify/brainstorm/decide on any tooling that exists or that could be built to help users switch to migrate to boxo. For example, a script you could run at the root of your repo. It would identify what you have that has now been moved into go-libipfs and then offer to update go.mod and your import paths? If we think there is something that would be really useful to get done here, I'm game for us to carve time for it (or to engage IPDX).

It should also identify if one has a "go-libipfs" dependency that should switch to "boxo" as a result of the renaming working happening in #215

[guseggert]

Took a stab at something like this: https://github.com/ipfs/go-libipfs/blob/feat/consumer-migration-tool/cmd/migrate/migrate.go

It basically just rewrites import paths for repos that were moved into go-libipfs. If there were any subsequent breaking changes, it's still on the consumer to work through those. And it also doesn't do anything to help with managing versions (generally consumer can just use the latest version, which Go does by default). One thing this might be able to do is to also detect transitive dependencies of modules that were moved into go-libipfs, to prevent having multiple versions of the same library in the dependency graph (ex if a consumer upgrades to go-libipfs but one of its dependencies still uses an older archived repo).

[guseggert]

I've added some functionality to that tool which checks the consuming repo for any dependencies (direct or transitive) which were migrated to go-libipfs, it prints something like this:

Warning: you still have dependencies on modules which have migrated to go-libipfs.
You should consider not having these dependencies to avoid multiple versions of the same code.
You can use 'go mod why' or 'go mod graph' to find the reason for these dependencies.

Dependent module versions:

github.com/ipfs/go-bitswap v0.11.0
github.com/ipfs/go-ipfs-files v0.3.0
github.com/ipfs/interface-go-ipfs-core v0.10.0
github.com/ipfs/go-unixfs v0.3.1
github.com/ipfs/go-path v0.3.0
github.com/ipfs/go-namesys v0.7.0
github.com/ipfs/go-ipfs-keystore v0.1.0
github.com/ipfs/go-ipns v0.3.0
github.com/ipfs/go-blockservice v0.5.0
github.com/ipfs/go-ipfs-chunker v0.0.1
github.com/ipfs/go-fetcher v1.6.1
github.com/ipfs/go-ipfs-blockstore v1.2.0
github.com/ipfs/go-ipfs-posinfo v0.0.1
github.com/ipfs/go-ipfs-util v0.0.2
github.com/ipfs/go-ipfs-ds-help v1.1.0
github.com/ipfs/go-verifcid v0.0.2
github.com/ipfs/go-ipfs-exchange-offline v0.3.0
github.com/ipfs/go-ipfs-routing v0.3.0
github.com/ipfs/go-ipfs-exchange-interface v0.2.0

[BigLep]

@guseggert : I updated the issue description, but tooling should also account for anyone who is using go-libipfs rather than boxo (given the renaming effort of #215 ).

[lidel]

@guseggert quick feedback on feat/consumer-migration-tool/cmd/migrate/migrate.go (used in bifrost-gateway and caboose PRs)

• worked as expected, thanks!
• rename binary to boxo-migrations so there is no conflict with other things on PATH
• thoughts on automatically running go mod tidy after successful update-imports? it will surface issues early (if any)

[guseggert]

Thanks appreciate the feedback, will incorporate.

[guseggert]

Addressed that feedback and added README documentation here: #243

[guseggert]

I think we're good here, at least for the MVP of this.