5 ms·
> 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 su
by apunic 12y ago
> 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.
- pjc50 12y agoWe 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 12y agoOne 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.
- deleted 12y ago[deleted]
- howeman 12y agoThe 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).
- voidlogic 12y ago>>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.