shurcooL / Go-Package-Store

An app that displays updates for the Go packages in your GOPATH.
MIT License
900 stars 29 forks source link

Add support for Go modules. #92

Open dmitshur opened 6 years ago

dmitshur commented 6 years ago

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 commented 5 years ago

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

bep commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

dmitshur commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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

image

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.