-
Notifications
You must be signed in to change notification settings - Fork 29
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
Possible enhancements. #8
Comments
What about displaying just the packages that are imported in the current directory or something like that? Nice project btw. |
I would like to see a "Delete" button. |
I think an ability to delete Go package repos (safely) would be nice, but it'd be great if it were done on a separate tab, where you can just list all packages (instead of updates). |
+1 |
+1 to delete repos (especially unused ones) |
On the topic of deleting "unused" repos (well, let's say finding them; deleting is orthogonal). I've been thinking about it, and realized the following. In order to determine what Go packages (or repos) are unused, you need to provide, as input, all the packages you care about being able to build (and possibly what additional build tags or OS/arch combinations you want to be able to build under), as well as if you want to preserve packages needed for running their tests. Without that information, it's physically not possible to determine what is "unused" (aside from making some guesses or assumptions about what you use/care about). I think I'll most likely want to start off with a simpler milestone and focus on listing all Go packages (on a separate tab) and have the ability to safely move them to trash (if they have no content aside from what can be retrieved by go-getting them again). Afterwards, I can think about answering the question "what other packages/repos import something from here", via I also want to add support for easily moving Go packages between different GOPATH workspaces. I think that's something where GPS could be helpful, since doing that manually is somewhat painful. |
This is a large change that primarily moves HTML rendering and display logic from backend to frontend (#67). Previously, the HTML for displaying updates was rendered on backend and streamed to browser. This worked surprisingly well and got me far, but in order to be able to have more fine grained control over frontend details, it was no longer viable to keep doing that. Now, the HTML is fully rendered on frontend, and most of the logic resides on the frontend. The backend provides services to the frontend. See issue #67 for full rationale why this is desired. Implement a long-standing feature request of having an "Update All" button (#6). This is both made possible and easy thanks to the frontend HTML rendering. This change partially helps #63, but also enables potential future changes to help it even more. In general, the move to frontend HTML rendering will help potentially achieve some of enhancements described in #8. Close #66 by removing the popup altogether. It wasn't well implemented, so it's better to remove. In the future, a better replacement implementation of the notification (without the modal popup) can be considered. Resolves #67. Closes #66. Helps #63. Helps #8. Resolves #6.
This is a large change that primarily moves HTML rendering and display logic from backend to frontend (#67). Previously, the HTML for displaying updates was rendered on backend and streamed to browser. This worked surprisingly well and got me far, but in order to be able to have more fine grained control over frontend details, it was no longer viable to keep doing that. Now, the HTML is fully rendered on frontend, and most of the logic resides on the frontend. The backend provides services to the frontend. See issue #67 for full rationale why this is desired. Implement a long-standing feature request of having an "Update All" button (#6). This is both made possible and easy thanks to the frontend HTML rendering. This change partially helps #63, but also enables potential future changes to help it even more. In general, the move to frontend HTML rendering will help potentially achieve some of enhancements described in #8. Close #66 by removing the popup altogether. It wasn't well implemented, so it's better to remove. In the future, a better replacement implementation of the notification (without the modal popup) can be considered. Resolves #67. Closes #66. Helps #63. Helps #8. Resolves #6.
cmd/goimporters
to achieve this.gopathutil.RemoveRepo()
to achieve this.go get -u -d
in some way?The text was updated successfully, but these errors were encountered: