switch to go modules

[b5]

go-ipfs is set to release v0.4.20 this week, which will be the first release after the switch from gx to go modules. If you're interested in the history of the switch for go-ipfs, these issues are the biggies:

• discussion around the switch
• switch implemented on go-ipfs
• v0.4.20 release

Once v0.4.20 is out, I'd like our next release to make the switch. It'll simplify our build story, and bring us back into line as a "stock" go project. We also have a timing window here: when go 1.13 is released go modules will be enabled by default. The release isn't until July, but I'd like to be well over to the go module ecosystem by then.

Reading up on go modules

Start here: https://blog.golang.org/using-go-modules

Planning the switch

I'd like this switch to cause minimal disruption to our day-to-day development, but some disruption is necessary just to get everyone comfortable with a new way of working. Switching to go modules will require a PR on every repo we manage (everything under github.com/qri-io), so let's use that to our advantage: everyone on Qri engineering needs to author at least one PR that switches a repo to go modules.

We'll start at the bottom of the dependency tree and work up, leaving PRs unmerged until one is open & ready on all repos. We'll take a day to merge everything, and cut a patch release that same day. That patch release should include detailed notes on the switch, and instructions on how to transition to our new development process. Things like make update-deps and make install are all going to change (in implementation at least).

I've added go module support to jsonschema & jsonpointer, they're worth checking as a starting point.

Releases & CHANGELOG.md

go modules are build on semantic versioning, so to do go modules right, we need to improve our story on subpackage releases. Basically this means doing to all our packages what we currently do with github.com/qri-io/qri: add make update-changelog, generate a proper CHANGLOG.md, and issue pull requests that cut versions on a release cycle. As part of this project we should aim for all projects to have make update-changelog and CHANGELOG.md. Our conventional commit adherence is paying dividends here.

If a package has no prior release, let's start at v0.1.0

gx

Packages that use gx will need some additional steps:

• gx dependencies need to be switched to depend on whatever version is specified in the go.mod of the forthcoming go-ipfs v0.4.20 release, import paths in code must be re-written from gx/ipfs/Qm.../foo to the standard github.com/go-libp2p/foo
• circleci test steps that use gx need to be removed
• documentation needs to be updated, especially installation steps

---

Execution

As mentioned above, let's divide-and-conquer. All of these repos need a PR that:

• cuts a new release upon merge
• adds make update-changelog
• brings CHANGELOG.md up to date
• adds go.mod

Repos that need go.mod / go.sum w/ no gx deps (and no deps with their own gx deps)

• ioes
• jsonschema
• jsonpointer
• varname
• doggos
• mkpkg
• deepdiff
• iso8601

gx'd Repos

repos with code that has import gx/ipfs/Qm... somehere in their source

• dag
• qfs
  startf startf is merging into qri-io/qri see bring startf inline #785
• p2p-testbed _skip this until we decide the direction of the repo: This repo is out of date p2p-testbed#2
• dataset
• qri

repos that have deps with gx

• starlib
• starpg
  dsdiff merged into qri-io/dataset see chore(release): release v0.1.1 dataset#194
• registry
• qri-datapackage

[b5]

This ended up being helpful & informative: https://github.com/golang/go/wiki/Resolving-Problems-From-Modified-Module-Path

[b5]

This blog post is also helpful. Includes a section for dealing with reliance on $GOPATH:
https://blog.golang.org/modules2019

which points to a new package for this problem:
https://godoc.org/golang.org/x/tools/go/packages

I'm not yet sure if we can use this package package to fetch binary testdata type stuff. Should do some testing.

[b5]

omg u guyz we did it