Skip to content
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

Open
3 tasks
dmitshur opened this issue Jul 13, 2014 · 6 comments
Open
3 tasks

Possible enhancements. #8

dmitshur opened this issue Jul 13, 2014 · 6 comments

Comments

@dmitshur
Copy link
Member

dmitshur commented Jul 13, 2014

  • Have a way to see the list of all packages that (directly or indirectly) depend on the shown repo.
  • Have a way to (safely) remove the shown repo (move it to trash only if there are no local changes).
  • Display errors when doing go get -u -d in some way?
@gonzaloserrano
Copy link

What about displaying just the packages that are imported in the current directory or something like that?

Nice project btw.

@uwe
Copy link

uwe commented Sep 24, 2015

I would like to see a "Delete" button.

@dmitshur
Copy link
Member Author

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).

@uwe
Copy link

uwe commented Sep 25, 2015

+1

@mholt
Copy link

mholt commented Mar 10, 2016

+1 to delete repos (especially unused ones)

@dmitshur
Copy link
Member Author

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 cmd/goimporters or similar.

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.

dmitshur added a commit that referenced this issue Feb 25, 2017
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.
dmitshur added a commit that referenced this issue Apr 13, 2017
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants