Add support for Go modules.

[dmitshur]

Go Package Store was created for working with the current go get -u model with a GOPATH workspace. The vgo experiment (https://research.swtch.com/vgo) considers changing that significantly. This is both an opportunity and a potential requirement to keep Go Package Store useful.

This issue is to track information and developments in this area.

I haven't explored vgo yet aside from reading over the announcement posts.

[dmitshur]

I plan to implement Go module support in Go Package Store during this year.

[bep]

I'm not a big fan of people chiming in on issues just to say "I want this", but I was pulling the direct changes to Hugo yesterday, and even if the number of changed modules wasn't that high, doing a manual inspection of the changes (finding the repo on GitHub, browse the commit log) was time-consuming... I suspect most people just close their eyes and go a go get -u ./....

[ligustah]

@bep I've been using https://dependabot.com/ for a while (it became free after Github acquired them). Assuming you are on Github, it's just a couple clicks to install and it will open PRs with updates to your go.mod file, including changelogs/commits from the upstream module.
Can highly recommend it for keeping your dependencies up to date (and not just Go, for that matter)

[bep]

@ligustah OK, that I didn't know. Thanks, I will try.

[dmitshur]

By now I'm very familiar with module mode. In order to implement support for it, I need to make decisions about what updates to display.

In GOPATH mode, there was only one obvious answer: display all updates that you would get with go get -u, the only possible update operation.

In module mode, there are more possibilities/questions:

• display updates only to direct module requirements, or indirect as well
• display only the latest release or pre-release versions, or the latest pseudo-versions too

Perhaps to achieve the best experience, a UI redesign will be necessary. But I think it makes sense to start by finding a reasonable way to reuse the existing UI, and then consider further changes based on the experience.

[dmitshur]

I've thought about this and picked some initial answers to start with.

display only the latest release or pre-release versions, or the latest pseudo-versions too

For now, I'll do the simplest thing, which is to do what the go command does. If it's desirable to provide more flexibility, that can be done later.

display updates only to direct module requirements, or indirect as well

For now, I'll include indirect updates by default, or make them optional via a flag. I'll try to make it show up in the UI whether or not it's an indirect dependency.

[dmitshur]

Here's a rough first draft (with some version information quickly added to the title):

It generally seems to work well, but it's pretty clear module mode will need some UI changes to better visualize the old and new version, and likely not display indirect updates by default.