3 ms·
I actually haven't even used gopkg.in myself. Gustavo Niemeyer just released it and has been pushing it as one way to promote API stability. I agree with him an
by burntsushi 13y ago
I actually haven't even used gopkg.in myself. Gustavo Niemeyer just released it and has been pushing it as one way to promote API stability. I agree with him and plan to migrate to the scheme soon, as there are a few people using my libraries.
With that said, I doubt very much it will make it into the official toolchain. There's really no point if it can be offered just as well by a third party. For example, godoc.org has proved invaluable but isn't official.
Also, keep in mind that gopkg.in is still pretty new, and I believe Gustavo has said that adding support for other web sites or revision control systems is perfectly doable. Just wanted to get something started for the lowest common denominator, I suspect. :-)
- grey-area 13y agoThe advantage of having it in go get would be that no one has to rely on a single point of failure like gopkg.in, nor would they have to get new urls recognised there, and finally that it could become an accepted way to version dependencies instead of the versionless future golang lives in right now. They did add versioning to the lang after a while so hopefully this will be similar. It's not a huge deal anyway right now, it'll become more important as the pkg universe grows.