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

[Gustavo Niemeyer]

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]

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]

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]

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]

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)

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

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]

Guessing that A+0, B+0 means you have no preference?

--

Joshua Poehls

--

[jimmy frasche]

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]

Me neither. 

[James Wendel]

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]

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]

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]

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]

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

gopkg.in/github.com/user/pkg/subpkg/v1

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]

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)

(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]

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]

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]

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]

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]

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.

--

Saludos, Gabriel

http://aprendiendodeandroidymas.com/

http://culturalibrerosario.org/

[Péter Szilágyi]

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]

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]

+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]

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]

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]

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]

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]

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]

Definitely A+1. 

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

[Gustavo Niemeyer]

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]

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]

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]

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]

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