search

shurcooL / Go-Package-Store

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

Request: An option to ignore private repos #91

Closed mvdan closed 2 years ago

mvdan commented 6 years ago

If I have a private repo in my GOPATH, chances are it's a work repository or a private/personal thing. In both cases, I'm very likely to be a contributor, so Go-Package-Store is of little use.

I understand that I can set up a GitHub token, but that's a different approach. I simply don't want the tool to check for updates on a repo if it notices it has no access to said repo.

I know this can be tricky, because a private repo is generally just a 404, just like a missing repo. So it would be fine if the flag was called -ignore-missing instead of -ignore-private.

dmitshur commented 6 years ago

The current solution is to do something like:

go list all | grep -v private/repo/to/exclude | Go-Package-Store -stdin

Or an alias version thereof to save on typing. This issue is very similar to #89.

I'm not sure if there's a reliable general way GPS can detect "private" repos, but I'll think about it a bit before closing.

mvdan commented 6 years ago

Thanks for the reply!

go list | grep does sound like a solution, I didn't know I could feed that into GPS. However, go list all on my system takes about five seconds, so I don't know if that's optimal. But if GPS would otherwise do the same work anyway, I guess it's the same.

dmitshur commented 6 years ago

It has to do roughly the same work, see here, but with two differences:

  1. Thanks to the parallelized and pipelined processing, it starts looking for updates as soon as some repos are discovered. It doesn't need to wait entire 5 seconds before it can get started.
  2. It stops after finding repository roots, without finding all individual Go packages inside, so it's a bit faster than go list all. Not by much though.

5 seconds for go list all is a bit lengthy but not too unreasonable if your GOPATH is quite large. You should ensure that you don't have any large extraneous files/folders in it that would slow down processing (it's okay if they begin with ., _ or are in testdata). See https://github.com/bradfitz/go-issue-mirror/issues/13 for more information on what that can be like.

mvdan commented 6 years ago

Ha, that's a good point. I never wondered why it was so slow. I tend to go get -d a lot of things, so yes, I have lots of crap.