gopkg.in package pages

[Gustavo Niemeyer]

gopkg.in now has nice package pages, including a map of available
versions for the given package:

https://gopkg.in/alexzorin/libvirt-go.v2

Thanks to Geert-Johan Riemer for the feature implementation.


gustavo @ http://niemeyer.net

[Wes Freeman]

Awesome. Looks great.

[Peer A.I.]

Looking good, but I just realized that there is a small inconsistency.

https://gopkg.in/qml.v0 adds the additional line "Refer to it as qml." 

while the livirt-go package doesn't. Is this behavior intentional?

By the way: it seems that it is now possible to refer to GitHub

projects that are not Go related. Is that correct? Maybe I just

missed the announcement. 

[Gustavo Niemeyer]

On Sat, Apr 5, 2014 at 2:24 AM, Peer A.I.
<peer.arami...@gmail.com> wrote:
> Looking good, but I just realized that there is a small inconsistency.
> https://gopkg.in/qml.v0 adds the additional line "Refer to it as qml."
> while the livirt-go package doesn't. Is this behavior intentional?

The service assumes that a clean repository name has a matching
package name, and "libvirt-go" cannot be a package name. Using
"libvirt" for the repository would add the package name hint, for
example.

> By the way: it seems that it is now possible to refer to GitHub
> projects that are not Go related. Is that correct? Maybe I just
> missed the announcement.

It won't dig in to investigate the content of the repository right
now, so yes, it might work. That said, the service targets Go packages
specifically. Anything else can easily be broken, and it will, if
people start abusing it.


gustavo @ http://niemeyer.net

[Peer A.I.]

Well maybe you don't have to check the whole repository. gopkg already

uses a branch/tagging convention, so how about an additional rule, like

having a "gopkg" tag? Of course, there might be some downsides with

this approach.

[Gustavo Niemeyer]

On Sat, Apr 5, 2014 at 2:32 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> The service assumes that a clean repository name has a matching
> package name, and "libvirt-go" cannot be a package name. Using
> "libvirt" for the repository would add the package name hint, for
> example.

I suppose go-foo and foo-go are going to be common for namespacing
well known names into a Go context, so these will be stripped out now,
which makes libvirt-go offer the package name hint too.

> Well maybe you don't have to check the whole repository. gopkg already
> uses a branch/tagging convention, so how about an additional rule, like
> having a "gopkg" tag? Of course, there might be some downsides with
> this approach.

Yeah, that's an alternative to be considered, but it's probably best
to keep it simple for now.


gustavo @ http://niemeyer.net

[Peer Aramillo Irizar]

Am 05.04.2014 08:09, schrieb Gustavo Niemeyer:

> On Sat, Apr 5, 2014 at 2:32 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> The service assumes that a clean repository name has a matching
>> package name, and "libvirt-go" cannot be a package name. Using
>> "libvirt" for the repository would add the package name hint, for
>> example.
> I suppose go-foo and foo-go are going to be common for namespacing
> well known names into a Go context, so these will be stripped out now,
> which makes libvirt-go offer the package name hint too.

That was actually the behavior I've expected, hence the confusion. :)

>> Well maybe you don't have to check the whole repository. gopkg already
>> uses a branch/tagging convention, so how about an additional rule, like
>> having a "gopkg" tag? Of course, there might be some downsides with
>> this approach.
> Yeah, that's an alternative to be considered, but it's probably best
> to keep it simple for now.

Coming to think about it, I like the idea of actively subscribing to gopkg

(using tags for example). First of all, you don't get hits for repositories

like https://gopkg.in/git/git.v1 this way. This might reduce the level of

confusion caused by repos that just happen to use the gopkg versioning

convention.

Another advantage would be that you don't have to use a certain naming

scheme you propably don't even like. And since using a naming scheme

that involves the term "go" is already prone to result in much noise (since

"go" isn't very unique), one could further reduce the number of unrelated

repos.

And last, you would be able to decide whether to use gopkg or not. You're

not just part of a service you might not even know about. Of course one

could argue that if you don't even know about it, you probably don't care.

[Carlos Castillo]

The only real way to be 100% certain of the package name is to download the code and run it through go/build. Even then, you might get the answer "main" if the package is an executable (not that you'd likely import that). If you aren't going to download and parse the files yourself, you might want to simply not provide a suggested package name at all. Either that or tell the viewer to look at the godoc.org documentation, which does download the code and parses it, so therefore can produce an accurate go package name (provided it's a valid package).

[Gustavo Niemeyer]

On Sat, Apr 5, 2014 at 6:48 AM, Carlos Castillo <cook...@gmail.com> wrote:
> The only real way to be 100% certain of the package name is to download the
> code and run it through go/build.

Indeed, and we may well do that at some point, but there are three
reasons why it feels okay to do that for now:

1) Names that are unrelated to the repository confuse not only the
service but also developers trying to use the package.

2) The service requires the package author to adopt it, and should not
be used for packages in the wild that do not recommend it. Authors can
easily tune to make the package name reasonable, and can also report
back if they find anything worth of attention.

3) So far, it feels consistently spot on.

Makes sense?


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

... and this problem is now gone entirely. gopkg.in now asks godoc.org
about the name and synopsis of the package. Changes contributed by
Geert-Johan too.

--

gustavo @ http://niemeyer.net