Re:Announcing the new Rust package manager, Cargo
by grey-area on Tuesday March 18, 2014 @02:15AM
(#7420446)
I put "package manager" in scare quotation marks because one of the design goals of Go is essentially to render most of the functionality of such package managers irrelevant.
Golang does have a de-facto package manager in go get (with its own conventions on file system layout etc), it just doesn't handle versioning. The Go packaging system is pretty good, but it isn't perfect, and I'm not convinced vendoring is a viable solution if you're going to be sharing code and collaborating on several open source projects - it's a recipe for lots of incompatible versions with security and other bugs unfixed floating around in different projects, and a lot of confusion from newcomers about the required version of a library because it is not specified anywhere.
The current approach works perfectly if you are working in-house, willing to do your own dependency resolution, and are happy to vendor your own dependencies - it's completely reasonable within one company or org to do this. However it fails in more collaborative or open-source environments like libraries shared on github depending on other libraries shared on github. I do think they need version pinning for that (in fact they have version pinning for the language in go get, just not for individual packages), it wouldn't be a large change.
For example, in the recent Stripe CTF, people ended up downloading and building different packages locally than those available on the server builds, because there was no clarity on which version was included. That was kind of annoying. It could be solved by vendoring, but then you have other issues in the long-term with relying on other people to keep their pkg dependencies up to date or you can be including two conflicting versions of a third pkg.
They've taken an interesting approach in trying to eschew versions (which avoids some problems with dependency resolution), but I'm not sure it is sustainable long-term. Didn't they also try to make golang itself version free initially?
Golang does have a de-facto package manager in go get (with its own conventions on file system layout etc), it just doesn't handle versioning. The Go packaging system is pretty good, but it isn't perfect, and I'm not convinced vendoring is a viable solution if you're going to be sharing code and collaborating on several open source projects - it's a recipe for lots of incompatible versions with security and other bugs unfixed floating around in different projects, and a lot of confusion from newcomers about the required version of a library because it is not specified anywhere.
The current approach works perfectly if you are working in-house, willing to do your own dependency resolution, and are happy to vendor your own dependencies - it's completely reasonable within one company or org to do this. However it fails in more collaborative or open-source environments like libraries shared on github depending on other libraries shared on github. I do think they need version pinning for that (in fact they have version pinning for the language in go get, just not for individual packages), it wouldn't be a large change.
For example, in the recent Stripe CTF, people ended up downloading and building different packages locally than those available on the server builds, because there was no clarity on which version was included. That was kind of annoying. It could be solved by vendoring, but then you have other issues in the long-term with relying on other people to keep their pkg dependencies up to date or you can be including two conflicting versions of a third pkg.
They've taken an interesting approach in trying to eschew versions (which avoids some problems with dependency resolution), but I'm not sure it is sustainable long-term. Didn't they also try to make golang itself version free initially?