-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tooling to minimize impact on those updating to boxo #181
Comments
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). |
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:
|
@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 ). |
@guseggert quick feedback on
|
Thanks appreciate the feedback, will incorporate. |
Addressed that feedback and added README documentation here: #243 |
I think we're good here, at least for the MVP of this. |
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
The text was updated successfully, but these errors were encountered: