gopkg.in/pkg/v2 vs. gopkg.in/v2/pkg

390 views
Skip to first unread message

Gustavo Niemeyer

unread,
Mar 27, 2014, 10:53:27 PM3/27/14
to golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
Hey there,

I've been talking to Kyle Lemons in that big thread about the update
on gopkg.in about the exact position of the version number in the
package path. The question is whether to use:

A)

gopkg.in/v3/pkg
gopkg.in/v3/pkg/sub
gopkg.in/user/v3/pkg
gopkg.in/user/v3/pkg/sub

B)

gopkg.in/pkg/v3
gopkg.in/pkg/v3/sub
gopkg.in/user/pkg/v3/pkg
gopkg.in/user/pkg/v3/pkg/sub


We're currently using A, and I'm willing to go over the trouble of
special-casing the current uses of gopkg.in that exist today for a
smooth migration if most people prefer B, just so we stick to the
convention most people would like to run with. Both me and Kyle Lemons
provided reasons to prefer either one or the other in the changes
thread, so if you can resist, please avoid much debate here, and
instead simply vote one of:

A+1
A+0
B+0
B+1.

I'm not going to vote.. I'm happy with either as long as we adopt some
kind of stable API strategy.


gustavo @ http://niemeyer.net

Pavan Kumar Sunkara

unread,
Mar 27, 2014, 11:14:53 PM3/27/14
to Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com, Kyle Lemons
A+1
> --
> You received this message because you are subscribed to the Google Groups "Go Package Management" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
> To post to this group, send email to go-package...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
- Pavan Kumar Sunkara

Andrew Gerrand

unread,
Mar 27, 2014, 11:25:18 PM3/27/14
to Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com, Kyle Lemons

On 28 March 2014 13:53, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
A+1
A+0
B+0
B+1.

I don't understand the options.

Dan Kortschak

unread,
Mar 27, 2014, 11:28:08 PM3/27/14
to Andrew Gerrand, Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com, Kyle Lemons
On Fri, 2014-03-28 at 14:25 +1100, Andrew Gerrand wrote:
> I don't understand the options.

Thank you, I thought it was just me.

Joshua Poehls

unread,
Mar 27, 2014, 11:40:52 PM3/27/14
to Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com, Kyle Lemons
Forgot to send to the list...
--------

Sorry if I'm missing something obvious, but is there a reason why we the following isn't an option?

C)


That is my preference since it keeps the version number always at the end in a consistent position regardless of sub-packages.

--
Joshua Poehls


Joshua Poehls

unread,
Mar 27, 2014, 11:42:09 PM3/27/14
to Andrew Gerrand, Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com, Kyle Lemons
Guessing that A+0, B+0 means you have no preference?

--
Joshua Poehls


--

jimmy frasche

unread,
Mar 27, 2014, 11:45:13 PM3/27/14
to golang-nuts, go-package...@googlegroups.com
I have no idea what those options mean, but any option that doesn't
always have the package name as the basename is a bad option.

kpo...@gmail.com

unread,
Mar 28, 2014, 12:22:10 AM3/28/14
to golan...@googlegroups.com, Gustavo Niemeyer, go-package...@googlegroups.com, Kyle Lemons
Me neither. 

James Wendel

unread,
Mar 28, 2014, 1:38:47 AM3/28/14
to golan...@googlegroups.com
I believe it should be most important data on the left and least important on the right. To me that would mean it should be ordered like:
Project/version
User/project/version

This follows how most people design rest APIs.

If go get allowed query params on URLs, I would say version should be part of the query param as it really is just augmenting which version of a package you fetch.

But that's just my opinion.

Alex Skinner

unread,
Mar 28, 2014, 1:48:50 AM3/28/14
to golan...@googlegroups.com
I'm in the pkg/v2 camp as well. The other way around makes it read like it's v2 of gopkg.in...

Henrik Johansson

unread,
Mar 28, 2014, 2:22:10 AM3/28/14
to golang-nuts
B+1 

I reads a little better.
"We are looking in the repo gopkg.in for package pkg of version v3" of course other constructs could be envisioned but i prefer the service/package to the left.


On Fri, Mar 28, 2014 at 6:48 AM, Alex Skinner <al...@lx.lc> wrote:
I'm in the pkg/v2 camp as well.  The other way around makes it read like it's v2 of gopkg.in...

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

Elson Wu

unread,
Mar 28, 2014, 2:35:28 AM3/28/14
to golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
A+

It would be better and easy when updating all sub folder to a new version.

在 2014年3月28日星期五UTC+8上午10时53分27秒,Gustavo Niemeyer写道:

Peter Bourgon

unread,
Mar 28, 2014, 3:48:02 AM3/28/14
to Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
The version of a package is subsidiary to its canonical name and therefore (I think) rationally belongs at the end.

While we're going through the trouble of changing the URL nomenclature, why don't we also address the inevitable problems that will come when we want to support something other than GitHub, and use the fully qualified name? (I see no way of avoiding this in the future; it's only a matter of when.)


That yields the pleasing and unambiguous definition:

gopkg.in/<normal import string>/<version>

Where <version> is any identifier that can be resolved by the VCS: branch, tag, etc. and also handily eliminates the arbitrary requirement to embed "major version" identifiers in the import path.

€0.02,
Peter.
--

Am Laher

unread,
Mar 28, 2014, 4:30:13 AM3/28/14
to golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
1. I prefer A [I don't understand the voting system either]. 

2. I'm not sure about having the version number at the end because the version number would inevitably get used as the qualifier for identifiers in the package.
For sure it would be mitigated by recommending using a PackageName alias in the import statement, but it would probably get misused I think.
i.e.
    meaningfulname.Do(thing)
vs 
    v3.Do(thing)
(harder to guess what the Do function might be doing, & upgrading would mean lots of search-replace - not just the import path)
vs
    import meaningfulname "gopkg.in/meaningfulname/v3"
    meaningfulname.Do(thing)
(may get forgotten but maybe fine with clear documentation)

Markus Zimmermann

unread,
Mar 28, 2014, 5:15:02 AM3/28/14
to golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
I am voting for C, what Joshua Poehls and James Wendel suggested.

gopkg.in/(user/)pkg/(sub/){version|branch}

Is more logical for me as the version is always on the right like it is with most(all?) software and APIs (go 1.2 vs 1.2 go). If the version would be on the left I would infer that it is the version of the service not of the package. I get it that the package name is changing with the version but I would just use an explicit package name for the sake of having a cleaner import / url.

In addition I have the same concern as Peter Bourgon. How do you distinguish where the package is hosted?

Peter Bourgon

unread,
Mar 28, 2014, 5:15:34 AM3/28/14
to Am Laher, golang-nuts, go-package...@googlegroups.com, Kyle Lemons
On Fri, Mar 28, 2014 at 9:30 AM, Am Laher <a...@laher.net.nz> wrote:
> 1. I prefer A [I don't understand the voting system either].
>
> 2. I'm not sure about having the version number at the end because the
> version number would inevitably get used as the qualifier for identifiers in
> the package.
> For sure it would be mitigated by recommending using a PackageName alias in
> the import statement, but it would probably get misused I think.
> i.e.
> import "gopkg.in/v3/meaningfulname"
> meaningfulname.Do(thing)
> vs
> import "gopkg.in/meaningfulname/v3"
> v3.Do(thing)

gopkg.in/github.com/user/foo/v3 would be defined and addressed as
"package foo", not "package v3".

chris dollin

unread,
Mar 28, 2014, 5:31:15 AM3/28/14
to golang-nuts, go-package...@googlegroups.com
I'm not sure I understand the choices that are presented.

However, I would be unhappy with any choice that didn't
routinely put the package name at the right-hand-end of
the package pathurithingy.

Having `import "buckets/and/spades/and/all/whatever/lastbit"`
import a package not named `lastbit` seems to me to be ...
asking for trouble.

v60/Chris



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Chris "allusive" Dollin

Gustavo Niemeyer

unread,
Mar 28, 2014, 5:52:49 AM3/28/14
to Andrew Gerrand, Kyle Lemons, golan...@googlegroups.com, go-package...@googlegroups.com

The options are either A or B (A+1 or B+1) or a slight tendency either way. But even just A or B is fine if you don't get it.

gustavo @ http://niemeyer.net

Gabriel Pozo

unread,
Mar 28, 2014, 8:44:53 AM3/28/14
to golang-nuts
B+1 for me, is more readable.


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Péter Szilágyi

unread,
Mar 28, 2014, 8:59:05 AM3/28/14
to Gabriel Pozo, golang-nuts
Hi all,

  B+1 for me too. Though, isn't there a double pkg in there? Shouldn't that be gopkg.in/user/pkg/v3 (without the extra trailing /pkg)?

  Although I can see the benefits and drawbacks of both schemes, somehow - being a service oriented person - I find service/version/resource more natural. Also in the directory layout for me at least it's more logical to drill down till the package and only then fan out to individual versions.

Cheers,
  Peter

Gustavo Niemeyer

unread,
Mar 28, 2014, 9:04:02 AM3/28/14
to Péter Szilágyi, Gabriel Pozo, golang-nuts
On Fri, Mar 28, 2014 at 9:59 AM, Péter Szilágyi <pet...@gmail.com> wrote:
> Hi all,
>
> B+1 for me too. Though, isn't there a double pkg in there? Shouldn't that
> be gopkg.in/user/pkg/v3 (without the extra trailing /pkg)?

No, that's how subpackages (packages withing /user/pkg) will look
like, and that's part of the rationale for not having it like that.

> Although I can see the benefits and drawbacks of both schemes, somehow -
> being a service oriented person - I find service/version/resource more
> natural. Also in the directory layout for me at least it's more logical to
> drill down till the package and only then fan out to individual versions.

Thanks for the feedback.


gustavo @ http://niemeyer.net

Joshua Poehls

unread,
Mar 28, 2014, 9:30:13 AM3/28/14
to Peter Bourgon, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
+1 for making the URL include the full import path (i.e. "github.com/").

--
Joshua Poehls


You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.

Vitor De Mario

unread,
Mar 28, 2014, 11:05:57 AM3/28/14
to Joshua Poehls, Peter Bourgon, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
B+1

Wouldn't it be better to organize the voting as an actual poll (strawpoll or something), while this thread is left for the discussion that is currently going on?

Alex Skinner

unread,
Mar 28, 2014, 11:23:24 AM3/28/14
to Joshua Poehls, Peter Bourgon, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
Specifically I'd be against this, especially in case that many sites are supported(bitbucket, gitlab, etc).  If one day github starts charging money, or goes out of business, a user I think should be able to update the gopkg.in link in a way that would not affect the user's code.  And if the full path is included, i'm not sure I'd understand the exact point of gopkg.in anymore vs everyone just doing this on github..

Thanks,
Alex
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Ze56kq2O8tk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

Gustavo Niemeyer

unread,
Mar 28, 2014, 11:27:28 AM3/28/14
to Alex Skinner, Joshua Poehls, Peter Bourgon, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
Yeah, we won't have the full host in the path like that. We'll likely
have other hosting sites in the future, but we can introduce that in a
nicer way and without breaking compatibility (bitbucket.gopkg.in, for
example). Let's just make sure we have a good strategy before
expanding further.
gustavo @ http://niemeyer.net

Peter Bourgon

unread,
Mar 28, 2014, 11:32:38 AM3/28/14
to Gustavo Niemeyer, Alex Skinner, Joshua Poehls, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
On Fri, Mar 28, 2014 at 4:27 PM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> Yeah, we won't have the full host in the path like that. We'll likely
> have other hosting sites in the future, but we can introduce that in a
> nicer way and without breaking compatibility (bitbucket.gopkg.in, for
> example). Let's just make sure we have a good strategy before
> expanding further.

Introducing a new subdomain to address the dimension of hosting
provider seems like an arbitrary, less elegant path to the same
destination, from where I sit. Can you provide some reasoning for the
categorical dismissal?

Peter Bourgon

unread,
Mar 28, 2014, 11:38:09 AM3/28/14
to Alex Skinner, Joshua Poehls, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
On Fri, Mar 28, 2014 at 4:23 PM, Alex Skinner <al...@lx.lc> wrote:
> Specifically I'd be against this, especially in case that many sites are
> supported(bitbucket, gitlab, etc). If one day github starts charging money,
> or goes out of business, a user I think should be able to update the
> gopkg.in link in a way that would not affect the user's code. And if the
> full path is included, i'm not sure I'd understand the exact point of
> gopkg.in anymore vs everyone just doing this on github..

gopkg.in is a version-pinning proxy to solve the issue of dependency
management for those client libraries that need it. I guess it's not
really meant to be central distribution point to abstract away hosting
providers, or act as the exclusive canonical name for a package.

peer.arami...@gmail.com

unread,
Mar 28, 2014, 11:57:21 AM3/28/14
to golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
Definitely A+1. 


On Friday, March 28, 2014 3:53:27 AM UTC+1, Gustavo Niemeyer wrote:

Gustavo Niemeyer

unread,
Mar 28, 2014, 1:03:23 PM3/28/14
to Peter Bourgon, Alex Skinner, Joshua Poehls, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
On Fri, Mar 28, 2014 at 12:32 PM, Peter Bourgon <peterb...@gmail.com> wrote:
> Introducing a new subdomain to address the dimension of hosting
> provider seems like an arbitrary, less elegant path to the same
> destination, from where I sit. Can you provide some reasoning for the
> categorical dismissal?

It's introducing a subdomain to address the dimension of a different
domain, which sounds reasonable to me. gopkg.in/bitbucket.com/ is
unnecessarily clunky, without any observable advantages.


gustavo @ http://niemeyer.net

Peter Bourgon

unread,
Mar 28, 2014, 1:10:11 PM3/28/14
to Gustavo Niemeyer, Alex Skinner, Joshua Poehls, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
The observable advantage is that gopkg.in/bitbucket.com/foo/bar
directly reflects/copies the existing import strings, whereas
bitbucket.gopkgin.in/foo/bar requires a semantic parsing of what's
defined to be an opaque identifier. (And treating github.com as the
"default" is I think a dubious distinction...)

jimmy frasche

unread,
Mar 28, 2014, 1:26:38 PM3/28/14
to Peter Bourgon, Gustavo Niemeyer, Alex Skinner, Joshua Poehls, Elson Wu, golan...@googlegroups.com, go-package...@googlegroups.com, Kyle Lemons
After considering the points raised in this discussion, I will only
use this service if the import path is

domain/version/original-import-path

such as

gopkg.in/v1/github.com/jimmyfrasche/goutil

It provides all of the information cleanly separated. It might be
weird to have the version before the package but anything else is
weirder

Kyle Lemons

unread,
Mar 28, 2014, 7:37:20 PM3/28/14
to Gustavo Niemeyer, golang-nuts, go-package...@googlegroups.com
I also have a domain (pkg.cx) that I've got lying around from some minor poking I did around the vanity URL thing awhile back.  Maybe the best way to satisfy everyone is to do both?
 
gustavo @ http://niemeyer.net

Gustavo Niemeyer

unread,
Mar 28, 2014, 9:58:21 PM3/28/14
to golang-nuts, go-package...@googlegroups.com
Just to close this thread properly, the new versioning pattern for
gopkg.in was defined considering everybody's feedback, and is
now live:

https://groups.google.com/d/msg/golang-nuts/-hfpKVkOy8w/I4H48otJ17UJ


gustavo @ http://niemeyer.net
Reply all
Reply to author
Forward
0 new messages