gopkg.in package pages

2070 views
Skip to first unread message

Gustavo Niemeyer

unread,
Apr 5, 2014, 12:39:06 AM4/5/14
to golan...@googlegroups.com
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

unread,
Apr 5, 2014, 12:50:14 AM4/5/14
to Gustavo Niemeyer, golang-nuts
Awesome. Looks great.

Peer A.I.

unread,
Apr 5, 2014, 1:24:29 AM4/5/14
to golan...@googlegroups.com
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

unread,
Apr 5, 2014, 1:32:00 AM4/5/14
to Peer A.I., golan...@googlegroups.com
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.

unread,
Apr 5, 2014, 1:56:07 AM4/5/14
to golan...@googlegroups.com
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

unread,
Apr 5, 2014, 2:09:24 AM4/5/14
to Peer A.I., golan...@googlegroups.com
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

unread,
Apr 5, 2014, 3:40:47 AM4/5/14
to Gustavo Niemeyer, golan...@googlegroups.com
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

unread,
Apr 5, 2014, 5:48:09 AM4/5/14
to golan...@googlegroups.com, Peer A.I.
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

unread,
Apr 5, 2014, 10:51:34 AM4/5/14
to Carlos Castillo, golan...@googlegroups.com, Peer A.I.
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

unread,
Apr 8, 2014, 8:49:54 AM4/8/14
to Carlos Castillo, golan...@googlegroups.com, Peer A.I.
... 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
Reply all
Reply to author
Forward
0 new messages