gopkg.in/v2/yaml broken (?)

[justinsb]

Not sure where the problem lies here, but external systems reference gopkg.in/v2/yaml , which cannot be resolved by go get (go get gopkg.in/yaml.v2 works though)

e.g. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/Godeps/Godeps.json

Is that incorrect, and/or did something change at gopkg.in?

[nathany]

That looks like the old-style urls. I'm not sure if they are still supported?

gopkg.in/yaml.v2 is equivalent, if you can update it.

[justinsb]

Thanks. The maintainer of the repo in question was able to fix his code (https://github.com/ghodss/yaml/pull/1), but anyone that uses Godeps (e.g. Kubernetes) is presumably broken until they also update. Although somehow Kuberentes is still building - despite having a non-existent Godep.

I don't see any documentation of old-style / new-style urls, or notification of any change (I feel like it would have been in the past few days...)

[ghodss]

I agree with @justinsb, this seems like a fairly painful breaking change without any announcement. It would be helpful to have much more warning for this kind of change, since godep breaks badly when an existing import path stops working.

[nathany]

If this happened recently, I can't imagine it being an intentional change.

[GeertJohan]

The new versioning style was introduced in commit https://github.com/niemeyer/gopkg/commit/3334c06823e90ea5648c10971a4c951dac5d722f, but a compatibility rule was added so existing imports using the "old" path would still work. I don't think the old paths are officially supported though, because at the time gopkg.in wasn't officially released/announced yet.

Anyhow, fo me go get gopkg.in/v2/yaml still works... I don't see why it shouldn't work for other users..