New gopkg.in version pattern is live

[Gustavo Niemeyer]

After much conversation, including private contact with people using
the service, there's indeed a preference for having the version
towards the end, although quite a few people would still like to hold
the package name as the last element. So, the new convention turns out
to be neither option A or B of the proposal, but instead a middle
ground that will probably serve both camps well.

With the changes now live, gopkg.in uses the following convention:

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

The advantages of this approach are:

- Local filesystem has a better organization
- The version is clearly associated with the repository path
- The package name is still the last path element (possibly with a
version extension)
- The path prefix matches the GitHub repository path
- This convention can easily be implemented without gopkg.in

The previous format is obsolete and should be replaced, but it
continues to work correctly for the time being for a smooth and timely
migration to the new pattern.

Thanks so much to everybody that contributed to the thread. It's
surprising how educated and contained the conversation was,
considering how prone to bikeshed this topic is.


gustavo @ http://niemeyer.net

[Am Laher]

Looks good.

I was only wary about this style because I didn't realise that package qualifiers are derived from the 'package pkg' statement rather than the basename of the import path. They're usually one & the same so it might confuse others too.

I suggest it might be worth noting this more prominently in the docs so people don't get discouraged. I would suggest a one-liner at the end of the 'Example' section, illustrating that e.g. 'd, err := yaml.Marshal(&t)' works automatically without requiring an aliased import path.

Just my 2c, well played for engaging the group in your decision-making. 

Cheers

[Kyle Lemons]

Ah, drat, this is what I get for reading the list in chronological order.  I guess I'll save pkg.cx for some other kind of rainy day :).

Thanks for taking the time to hash this out with everyone.  I think this is better than what I proposed, and satisfies all of the requirements I had.

 

gustavo @ http://niemeyer.net

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

[Gustavo Niemeyer]

That's a good idea, thanks. I'll push it up once I'm back in the laptop.

gustavo @ http://niemeyer.net

--

[Joshua Poehls]

Looks great to me. Thanks!

--

Joshua Poehls

[Gabriel Pozo]

Excellent, thanks!!

--
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/

[nvcnvn]

Greate solution!!!!

BTW, we have godoc.org, why don't we have gopkg.org ?