shurcooL / Go-Package-Store

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

Feature request: present websites using azul3d.org/semver.v1 nicely #24

Closed slimsag closed 9 years ago

slimsag commented 9 years ago

Background

The semver package (see GoDoc here) allows people to add support for semantic versioning of Go packages (basically what gopkg.in does) to custom domains (foobar.org/foopkg.v3).

Primarily it does mingling with the go-import meta tag and proxies git requests through the custom domain itself, so the meta tag doesn't contain a known code host (i.e. GitHub/Google Code) in it.

The meta tag for the azul3d.org/audio.v1 package looks like this:

<meta name="go-import" content="azul3d.org/audio.v1 git https://azul3d.org/audio.v1">

Where the "git" repository at https://azul3d.org/audio.v1 actually just proxies requests to github.com/azul3d/audio.

But the actual code host can be any arbitrary one (right now the package supports just GitHub, but it might support others like Google Code or private hosting in the future).

TL;DR

It would be cool if G-P-S could somehow talk with websites using semver to infer where they are hosted and present them as such. Basically:

Import path Hosted at Presented by G-P-S as
azul3d.org/pkg.v1 github.com/azul3d/pkg a normal GitHub package
azul3d.org/madness.v3 code.google.com/p/seperatehost a normal Google Code package
foobar.org/zed.v34-dev code.google.com/p/zeddev34 a normal Google Code package
evil.com private/non-public Git host as G-P-S presents any other generic package

There isn't anything in semver right now that particularly relates a site to any known code-hosting website.

I can add support to semver to show the underlying code host (i.e. the github repository) via e.g. a meta tag, but the question is what would be the best way to communicate this to G-P-S? I am open to any solution.

dmitshur commented 9 years ago

Thanks for opening this issue. The way G-P-S presents packages is an ongoing effort that can definitely be improved.

I want to point out a few things.

Private Code

Currently, G-P-S does not support presenting detailed information (like commit messages) about private packages. It supports updating them, because it just delegates all work to go get -u when the user presses Update button, so if they have access to that private repo, it will update no differently than if they had run go get -u in the terminal. See main.go#L86. Support for displaying private repo details may in theory be added in the future, but I currently have no interest in solving that.

Already Available Information

Next, I want to point out that G-P-S has a lot of information about Go packages and repos available to it when the presenter is executed. It runs locally and iterates over all Go packages/repos in the user's GOPATH, and performs remote calls to determine if there's a newer version available (and also sanity checks, like no dirty working tree, as updating such a package isn't viable). See main.go#L57-L61.

So, the key point is that, when G-P-S runs, the Go packages are already downloaded in the right place via go get and thus it knows what the remote is.

Because of that,

It would be cool if G-P-S could somehow talk with websites using semver to infer where they are hosted and present them as such. Basically:

Import path Hosted at Presented by G-P-S as
azul3d.org/pkg.v1 github.com/azul3d/pkg a normal GitHub package
azul3d.org/madness.v3 code.google.com/p/seperatehost a normal Google Code package

That is already being done to some degree (for repos with GitHub remotes) and can be expanded, because when picking a presenter, we can consider the remote URL of the given repo.

If that's what you want, there's no need to talk to semver during the update presentation point, since we're not doing the initial go get. Does that makes sense?

dmitshur commented 9 years ago

So if I understand your original post correctly, the only missing piece at this time is:

Import path Hosted at Presented by G-P-S as Already supported
azul3d.org/pkg.v1 github.com/azul3d/pkg a normal GitHub package yes
azul3d.org/madness.v3 code.google.com/p/seperatehost a normal Google Code package not yet

Is that right?

If so, I think that can be fixed by adding the following check:

// Underlying code.google.com remote.
case strings.HasPrefix(goPackage.Dir.Repo.VcsLocal.Remote, "https://code.google.com/"):
slimsag commented 9 years ago

If I git clone https://github.com/azul3d/audio into $GOPATH/src/azul3d/audio.v1 the result looks correct:

pic1

But if I go get azul3d.org/audio.v1 the result ends up as:

pic2

dmitshur commented 9 years ago

Okay, I can reproduce. That's a bug and will be fixed (given that the package has an underlying GitHub remote, there's no reason it can't present it more nicely).

dmitshur commented 9 years ago

It wasn't really a bug, but rather azul3d.org, due to its versioned nature, does not simply expose the github remote directly like some other vanity paths, and instead requires support similar to gopkg.in paths.

That's being added in #25.

Does that PR close this issue, or are there more points that can be improved/addressed?

slimsag commented 9 years ago

Does that PR close this issue, or are there more points that can be improved/addressed?

That PR is perfect.

The only reason I see to keep this issue open is for other websites using azul3d.org/semver.v1 in the future -- but we can address that then rather than now (as no other websites use it currently).

dmitshur commented 9 years ago

Yeah, I think it's better to open a new, more focused issue for that. I'll mark that PR to close this.