[apunic]

> You really don't need a package manager for Go. Honestly, the main reason [...] is because you're deploying source code to your production environment

Not sure if I would agree with that. A full-fledged package manager automates the process of installing, upgrading, configuring and removing software packages in a consistent manner. Dependency management and semantic versioning is an important part to provide this consistency. Wether you deploy source code or binaries does not make any difference why a package manager is always good to have.

[howeman]

The Go tool does do installation and upgrading. There's not really any configuring, and it'd be hard to do removal in any reasonable manner given how GOPATH works. What the Go tool does not do is isolate you from breaking changes upstream. For that you need someone you trust (which could be the package author or a copy of the code in gopkg.in), or be willing to fix breaking changes (which I do quite often).

[pjc50]

We really don't need any more binary package managers - that should be the responsibility of the platform you're deploying on. dpkg/rpm/etc on Linux systems, MSI on Windows, APK on Android, etc.

[pjmlp]

One reason I love package managers, is that as developer I don't want to produce a dpkg/rpm/tgz/apk/msi/ipa/p5i/depot multiplied by the different locations of include files, libraries, documentation across the said OS.

Specially in commercial software.

[voidlogic]

>>A full-fledged package manager automates the process of installing, upgrading, configuring and removing software packages in a consistent manner.

That sounds like deb(dpgk)/rpm's job. In golang-land I just need to use vendoring+godeps for repeatable builds.