Changes on gonuts.org (now gopkg.in)

[Gustavo Niemeyer]

Thanks to the good feedback provided both publicly and privately, a
number of changes were done to make the versioning github.com
redirector match people's expectations better:

1) Multiple people complained about the domain name; it's now
"gopkg.in", inspired by Simon Menke's fork of the redirection concept.

2) There were also multiple complaints about the go- prefix in
repositories; this is gone.

3) Some people prefer the use of tags and branches for versioning,
instead of the repository name. This works now, using the approach
described by Simon Menke (filtering of refs plus redirect on object
fetch). As a side effect of this feature, repositories that use tags
or branches to mark the version will git clone from gopkg.in, so the
original approach of using a versioned repository name still works for
those that prefer it. No configuration is necessary for either.. just
use your preferred approach and gopkg.in will figure it.

As a consequence of these changes, the package

gonuts.org/v1/yaml => github.com/go-yaml/go-yaml-v1

can now be

gonuts.org/v1/yaml => github.com/go-yaml/yaml

and contains a branch "v1".

The documentation at https://gopkg.in was updated to reflect those
changes, although there isn't much more to it than what's above.

According to the logs, by now all of the packages that were using
gonuts.org since the announcement were migrated and are working
properly on gopkg.in.

There are more improvements to come, but a couple of these were
disruptive, so it's good to have them in place before more people
start using it.


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

On Thu, Mar 6, 2014 at 5:03 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> can now be
>
> gonuts.org/v1/yaml => github.com/go-yaml/yaml
>
> and contains a branch "v1".

This should be gopkg.in/v1/yaml, of course.


gustavo @ http://niemeyer.net

[Péter Szilágyi]

Hi Gustavo!

  Thanks a lot for you work, this version looks a lot better (at least to me :) ).

  A small bug-report though: if I specify a non-existent repository, I get back a nice error message that it's not found. On the other hand if the repo *is* found, but the version number is *not*, I get back a blank page (i.e. http://gopkg.in/karalabe/v1/iris ).

Thanks for your efforts!

  Peter

gustavo @ http://niemeyer.net

--
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/groups/opt_out.

[Am Laher]

This is amazing (i.e. enabling `go get` to fetch specific branches based on rewriting URLs).

I didn't realise this was possible - well played and thank you.

[Nate Finch]

Enabling the use of tags and branches is awesome.  I was trying to figure out how to get that to work last night, glad Simon spoke up about it.

This is all great news.  Fantastic work, Gustavo.  

[Tamás Gulácsi]

Just what the doctor ordered!

Big thanks!

[Gustavo Niemeyer]

Another batch of improvements has landed with the following changes.
These are all covered in the documentation at https://gopkg.in as
well.

4) Much better error reporting

The service now says what it is trying to do that is not working. For example:

https://gopkg.in/v1/bad-docs
https://gopkg.in/v2/docs
https://gopkg.in/bad-user/v1/docs

The error pages are not visually pleasing yet, but that's a secondary
issue that will be solved in due time.


5) Full version support

The version numbers used in the URL and in the GitHub repository must
look like "v1", "v1.2" or "v1.2.3", where the numbers match the
semantic versioning scheme of vMAJOR[.MINOR[.PATCH]].

When using branches or tags, gopkg.in also understands that a version
such as "v1" may be satisfied by a tag or branch "v1.2" or "v1.2.1" in
the repository, and will select the best match satisfying the
requested version.


6) Default version zero

Version zero (v0) is reserved for packages that are so immature that
offering any kind of API stability guarantees would be unreasonable.
This is equivalent to labeling the package as alpha or beta quality.

It also makes sense to say that every Go package in GitHub that is not
being versioned is in fact unstable, so gopkg.in will now consider
repositories that have no tags or branches matching the version
pattern as having its master branch as v0.

This implies that every Go package in GitHub is now addressable by
gopkg.in. For example:

gopkg.in/niemeyer/v0/qml

This is just an easy way to get started, though, and to avoid problems
should only be used once the maintainers encourage the use of
gopkg.in.


Please let me know if you have any comments or find any problems.


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

On Thu, Mar 6, 2014 at 6:40 AM, Péter Szilágyi <pet...@gmail.com> wrote:
> A small bug-report though: if I specify a non-existent repository, I get
> back a nice error message that it's not found. On the other hand if the repo
> *is* found, but the version number is *not*, I get back a blank page (i.e.
> http://gopkg.in/karalabe/v1/iris ).

Yeah, the error reporting was pretty bad. It should be much better
now. Please let me know if you find issues again.


gustavo @ http://niemeyer.net

[Nate Finch]

Nice.  Honestly, I'm pretty happy having them just be text.  No need to search a big fancy page to figure out what the error was.

[Brian Fallik]

Cool project!

I found one typo on http://godoc.org/gopkg.in/v1/docs, "verioning".
I'm assuming you meant versioning.

brian

[Carlos Castillo]

The repository link at the top of the GoDoc page just returns you to the documentation page, and the source-code links for each function / method / etc... don't exist.

This may not be solvable, at least not without help from godoc.org

[Gustavo Niemeyer]

On Thu, Mar 6, 2014 at 7:25 PM, Carlos Castillo <cook...@gmail.com> wrote:
> The repository link at the top of the GoDoc page just returns you to the
> documentation page, and the source-code links for each function / method /
> etc... don't exist.
>
> This may not be solvable, at least not without help from godoc.org

It must be doable. I'll check with Gary what we might do to have this working.


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

Thanks. That's fixed.

--

gustavo @ http://niemeyer.net

[speter]

Thanks for the great service! I have some concerns about the description of versioning though.

The following are listed as changes that are fine to do without changing major version:

* Changing the type of a function or method parameter to an interface that
  is implemented by the old type, or a subset of the old interface
* Adding a variadic parameter to a function or method
* Some changes in the number of results in a function or method (see details below)

I believe these changes always have the potential to break dependent packages due to type change. That is, you will not be able to assign function or method value to the same type of variables you could in previous versions. Suppose you have:

package pkg
func DoIt(bytes.Buffer)

package user

var f func(bytes.Buffer) = pkg.DoIt

Then changing it to any of these will break user:

A) func DoIt(io.Writer)
B) func DoIt(bytes.Buffer, ...interface{})

C) func DoIt(bytes.Buffer) error

http://play.golang.org/p/w94Mwb6UYH (arranged to fit everything in single file)

The same applies for methods as well. In my interpretation of semver.org, these should be considered backwards incompatible changes.

Peter

gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

On Thu, Mar 6, 2014 at 8:11 PM, speter <spete...@gmail.com> wrote:
> I believe these changes always have the potential to break dependent
> packages due to type change. That is, you will not be able to assign
> function or method value to the same type of variables you could in previous
> versions. Suppose you have:

Indeed. There's a fine line there, but it's definitely wrong to report
these as reliable. I'll drop these from the description.

Thanks for the feedback,


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

There are now two instances of the service running, on New York and
San Francisco, with automatic failover setup so that the service
should remain up even if some bad things happen.

In a moment I'll take one of them down to ensure it's all working
properly, so you may see a short hiccup before the secondary takes
place.

[Gustavo Niemeyer]

All went well. The service can now survive traditional crashes and
network outages without me being around.

[Johan Samyn]

Hi Gustavo,
Any chances this gets extended to working with Mercurial repo's (on
Github), and with Bitbucket (git + hg)?

________________________________________________________________________
"Perfection seems to be achieved, not when there is nothing more to add,
but when there is nothing left to take away." - A. de Saint-Exupéry

[Gustavo Niemeyer]

On Sun, Mar 9, 2014 at 4:51 PM, Johan Samyn <johan...@gmail.com> wrote:
> Hi Gustavo,
> Any chances this gets extended to working with Mercurial repo's (on Github),
> and with Bitbucket (git + hg)?

There's a good chance we'll add other services. Let's consider that
after we gather some more experience.


gustavo @ http://niemeyer.net

[nvcnvn]

Hi Gustavo,

I wonder the repo name with CamelCase will work?

I have try some of my repo with gopkg.in/my-github-account/v0/my-repo and it work just fine.

But with gopkg.in/my-github-account/v0/MyOtherRepo and the server return "Unsupported URL pattern;...".

[Gustavo Niemeyer]

Ah, sorry about that. I'm happy to fix it. What's the actual repository name?

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

[Joshua Poehls]

Any plans to support other code hosting sites beyond GitHub? Bitbucket is of particular interest to me.

--

Joshua Poehls

--
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/groups/opt_out.

[Gustavo Niemeyer]

If you have a project you're willing to use it with, I can do
something about it sooner rather than later.

[Joshua Poehls]

No rush. I don't have a project yet - my only public Go package is on GitHub. Though I do use Bitbucket for private repos.

I was mostly curious about future plans - especially since you the gopkg.in URLs don't include "github.com" like you might expect.

--

Joshua Poehls

[David Skinner]

I was wondering about a deeper numbering system.

  vSDK.MAJOR.MINOR.PATCH

considering that a number of us are writing wrappers of outside libraries.

[Alex Skinner]

Hi Gustavo,

I know little about the innerworkings of the project at this time, but can appreciate its goals and functions.  So please excuse/educate me if the below seems out of scope.

Assuming it supports these sources in time, would it be possible or worth the effort to have some type of failover system in place?  That is, I could host a project in github and in bitbucket, and if github one day shuts down, no worries, it will simply use bitbucket instead.

I ask mainly because I was working through some qml examples earlier today, and noticed go get just sat and failed.  Come to find out, github was under another DDOS and unavailable.  I'm not sure it's worth the effort, but it would have been nice if a contributor could list multiple sources, so that in such cases, it just pulls from the next available.  In theory it's a rather limited use case, but in reality, if github went down/out of business permanently, it would be disastrous.

I do have some experience in such systems(if curious - mainly in dns failover logic) - it's not particularly hard, but if you agree and need the cycles, I would be willing to help.

Thanks,

Alex

[Gustavo Niemeyer]

Hey Alex,

On Sat, Mar 22, 2014 at 3:05 AM, Alex Skinner <al...@lx.lc> wrote:
> Assuming it supports these sources in time, would it be possible or worth
> the effort to have some type of failover system in place? That is, I could
> host a project in github and in bitbucket, and if github one day shuts down,
> no worries, it will simply use bitbucket instead.

We do have failover in place, in the sense that multiple machines have
to die for the service to fall down, but having the same URL pointing
to multiple code sources seems problematic, as they could easily go
out of sync and give different results. It's also hard to avoid a DDoS
in an effective way.. the system may look offline, even if neither
github or gopkg.in are offline, simply because the network path is
overloaded.

> I do have some experience in such systems(if curious - mainly in dns
> failover logic) - it's not particularly hard, but if you agree and need the
> cycles, I would be willing to help.

Thanks for the offer. DNS failover is already in place, but I'll
certainly get in touch if further help is necessary.


gustavo @ http://niemeyer.net