8 ms·

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your p

by NateDad 12y ago

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want a different version, you need a different repo. There are some tools to mitigate this, so that you can get away with a different branch per version (see http://gopkg.in http://gopkg.in), which can make it a little nicer for the maintainer to deal with multiple branches. To the consumer, it still looks like a different repo (i.e. every different version is a different URL to a repo). Note that because Go is a compiled language, the only time versioning comes into play is a development time. As long as your developers are using the right version, you never have to worry about versions during deployment. Now, if you're concerned that your project depends on code repos from external sources, then there are several tools that can insulate you from third parties doing stupid stuff. The most complete and best one is called godep, which basically has two modes - reliable and paranoid. The reliable mode insulates you from changes made to a repo you depend on by recording the exact VCS revision your project is using and always checks out that commit. That way, if an upstream repo checks in a breaking change, it won't affect you (and you control when you update to newer commits in that repo). Paranoid mode actually copies all the code from your dependencies into your own repo. This insulates you from upstream repos getting deleted. And of course, this gives you the ability to test out upstream changes before integrating them into your project. The tool makes it easy to copy all of your dependencies at once with a single command, so it's not a huge hassle to do (which it would be if you had to do it by hand).

eddieroger 12y ago
I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that scenario should be well prevented, but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you.
- lucaspiller 12y ago
  A lot of the work I do involves legacy Ruby software. Fortunately there has always been (well, since Ruby got popular) Rubygems which is equivalent to gopkg.in - I have been burned a couple of times though when authors have removed old libraries. For the last few years Bundler (http://bundler.io/ http://bundler.io/) which uses Rubygems has been the standard way to lock versions of libraries, and before that vendoring was widely used. When you pick up the maintenance of an old application you have to reinstall the dependencies from scratch if you aren't using vendoring or Bundler. Each method has their advantages and disadvantages, but both are much better than praying that the library author hasn't introduced a breaking change in a release since the library was last used. Although it isn't the same when you are deploying Go applications, development has exactly the same issues as Ruby without locking the dependencies.
- jerf 12y ago
  "but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you." If your build process downloads anything from the Internet, your build environment can change on you. Networks can always fail. At best you can detect this occurring and have your build process scream and die, but it can't be fixed. Note the complete lack of the word "Go" in the previous paragraph. If other languages provide package managers that make it easy to download code from the Internet during your build process, they are tempting you to do wrong things. You should be in personal possession of everything you need to do a full build, whatever that may be (source or otherwise). And, again, note the complete lack of the word "Go" in that sentence. This has nothing to do with Go. If you are depending on package managers to download your code from external sites during a build, stop reading this right now and GO FIX THAT. Seriously. Someday it will bite you, hard. And may Turing & Knuth help you if you're downloading packages with unpinned versions that can just upgrade to whatever they want, whenever they want. Now I will actually use "Go" in a sentence. The fact that Go expects you to vendor your source I do not consider a problem with the language. The fact that it fails to ship with a blessed tool for doing so is a potentially legitimate criticism, but the fact that it fails to ship with a tool that begs you to do the easy, wrong thing is a feature, not a bug. I wouldn't be surprised that they eventually bless something out of the community. Godep seems to be the current leader. Personally I can't recommend or anti-recommend any of them, I've just been vendoring by hand since I'm only using a handful of libraries, and the cost/benefit hasn't worked out in favor of learning something to save me mere minutes of effort. I know where to find solutions if that ratio ever changes.
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 ago
  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 12y ago
    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.
- deleted 12y ago
  [deleted]
- howeman 12y ago
  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).
- 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.
copsarebastards 12y ago
> You really don't need a package manager for Go. "You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement. I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core development team has made it unclear whether they would even accept some of these features. I get that compilation performance is a high priority, but they've missed the big picture, that developer time also matters. The following exemplifies the problem: > Note that because Go is a compiled language, the only time versioning comes into play is a development time. Oh, that won't affect me at all; development time is only like 90% of the life of a project.
- jerf 12y ago
  The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inability to have a sensible discussion about generics within the community due to the near inability to have a sensible discussion about generics outside of the community. It isn't all necessarily hunky-dory. But if you haven't used Go, which is what it sounds like to me, you don't understand the current situation's cost/benefit analysis and are unlikely to be able to "just" "solve" the community's "problems" without such an understanding. Step 1 of any engineering effort is identify the problem, and it can never be skipped, no matter how sure you are you can this time. If you're not a Go user, you've skipped this step. Of course you're free to A: not be a Go user for any reason you choose and B: say whatever you like about Go from the outside. And I really mean that, quite deeply, not merely as a rhetorical flourish. There's too many languages to become expert in them all and we all must choose carefully according to our own knowledge and desires. My only point here is only that you shouldn't expect the community to be enthralled with the resulting commentary.
  - copsarebastards 12y ago
tveita 12y ago
I would classify godep as a package manager in the same vein as bundler, pip, npm, etc., and in my experience it is absolutely essential if you still want your Go code to compile a month after you wrote it. I think the bit about source versus binary deployment is a bit of a red herring. It's not like any true Scotsman is deploying by running pip update in production either. As a developer you want to have code that compiles at all times. Having a binary you can't reproduce or change isn't going to be much comfort. If you're going to use third party libraries there is no reliable way to judge the stability of either the libraries you use directly or all your transitive dependencies. Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. Dependency management is not optional, but unfortunately Go makes it easy to hurt yourself by providing climbing holds without a safety harness. It isn't obvious to new programmers that they should use godep before they come back to an older project and it won't compile anymore.
- NateDad 12y ago
  >Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. I'm not sure what you mean by "conflict". That's the nice thing about the way go packages work. There's no v1 of a package and v2 of a package. All packages are different. If one dependency uses foo.v1 and one uses foo.v2 ... they don't conflict. They're as different to go as foo.v1 and bar.v1. >Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. Again, this just doesn't happen. A dependency has one canonical location. If the code changes at that location, it changes for anyone that uses that code. Yes, it's possible this could break only part of your code, if only part of your code was relying on the old behavior/API... but that should be rare (and if it happens, it means you can't trust that third party to stay stable). I think most people who complain about Go lacking versioning of packages are still stuck in the mindset of pip, npm, etc, where versions are fungible, and your code doesn't know exactly what version it might be working against. This is just not the way Go works. There's one and only one version of a dependency that your project sees. Anyone using that dependency uses the same version. If the dependency's code compiles on its own, it'll compile on your machine, too.
orkoden 12y ago
An example for a dependency management package manager for a compiled language is [cocoa pods](http://cocoapods.org http://cocoapods.org) for Objective-C. It's really popular with iOS and OS X developers. Or look at [cabal](https://www.haskell.org/cabal/ https://www.haskell.org/cabal/) for Haskell. It's a package manager that doubles as build system. It helps when you use external open source projects and want to update it to a new version. With go you have to keep track of you external dependencies and their versions on your own.
- pjmlp 12y ago
  Just to extend your list. dub for D, http://code.dlang.org/ http://code.dlang.org/ cargo for Rust, https://crates.io/ https://crates.io/ biicode for C and C++, https://www.biicode.com/ https://www.biicode.com/ NuGet for C and C++, http://docs.nuget.org/consume/support-for-native-projects http://docs.nuget.org/consume/support-for-native-projects OPAM for OCaml, https://opam.ocaml.org/ https://opam.ocaml.org/
theseoafs 12y ago
So the "solution" to Go's package management is just statically linking every library you use?
EugeneOZ 12y ago
You really need to look at Cargo in rustlang to see what good package manager can do and how it improves development.
EugeneOZ 12y ago
Please somebody explain me how to manage next situation without manual copying of code and forking repos (in other words, we need to still be able get updates for minor versions from repositories). GOROOT/ pkg src/ lib1 app1 app2 And app1 requires lib1 version 3.x, app2 requires lib1 version 1.x. What can we do? Also, on whole this page https://golang.org/cmd/go/ https://golang.org/cmd/go/ I can't find ANY info, about how to fetch exact version from repo, not the master branch. In Go world all master branches are for stable code only, not for development? And all tools have only one version?
- NateDad 12y ago
  There's no such thing as lib1 version 3.x. lib1 is a single version. Every import path is a unique package. If you want to make a new version of lib1, you need to give it a different path. This can be as easy as manually inserting "v2" in the path, like /lib1/v2/ or /v2/lib1/ There's no way to use "go get" to get anything other than the head of the master branch... at least, not by default. If you use a service like http://gopkg.in http://gopkg.in then you can encode a version in the url/import path which can then redirect to a branch in github, so for example import "gopkg.in/natefinch/lumberjack.v2" will get the v2 branch of github.com/natefinch/lumberjack (gopkg.in does this with some git magic)
  - EugeneOZ 12y ago
    > There's no such thing as lib1 version 3.x. lib1 is a single version. I don't agree with this part (or we are talking about different things), but thanks for the second part of reply. At least something :)

by NateDad 12y ago

eddieroger 12y ago

I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that scenario should be well prevented, but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you.

lucaspiller 12y ago
A lot of the work I do involves legacy Ruby software. Fortunately there has always been (well, since Ruby got popular) Rubygems which is equivalent to gopkg.in - I have been burned a couple of times though when authors have removed old libraries. For the last few years Bundler (http://bundler.io/ http://bundler.io/) which uses Rubygems has been the standard way to lock versions of libraries, and before that vendoring was widely used. When you pick up the maintenance of an old application you have to reinstall the dependencies from scratch if you aren't using vendoring or Bundler. Each method has their advantages and disadvantages, but both are much better than praying that the library author hasn't introduced a breaking change in a release since the library was last used. Although it isn't the same when you are deploying Go applications, development has exactly the same issues as Ruby without locking the dependencies.
jerf 12y ago
"but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you." If your build process downloads anything from the Internet, your build environment can change on you. Networks can always fail. At best you can detect this occurring and have your build process scream and die, but it can't be fixed. Note the complete lack of the word "Go" in the previous paragraph. If other languages provide package managers that make it easy to download code from the Internet during your build process, they are tempting you to do wrong things. You should be in personal possession of everything you need to do a full build, whatever that may be (source or otherwise). And, again, note the complete lack of the word "Go" in that sentence. This has nothing to do with Go. If you are depending on package managers to download your code from external sites during a build, stop reading this right now and GO FIX THAT. Seriously. Someday it will bite you, hard. And may Turing & Knuth help you if you're downloading packages with unpinned versions that can just upgrade to whatever they want, whenever they want. Now I will actually use "Go" in a sentence. The fact that Go expects you to vendor your source I do not consider a problem with the language. The fact that it fails to ship with a blessed tool for doing so is a potentially legitimate criticism, but the fact that it fails to ship with a tool that begs you to do the easy, wrong thing is a feature, not a bug. I wouldn't be surprised that they eventually bless something out of the community. Godep seems to be the current leader. Personally I can't recommend or anti-recommend any of them, I've just been vendoring by hand since I'm only using a handful of libraries, and the cost/benefit hasn't worked out in favor of learning something to save me mere minutes of effort. I know where to find solutions if that ratio ever changes.

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 ago
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 12y ago
  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.
deleted 12y ago
[deleted]
howeman 12y ago
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).
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.

copsarebastards 12y ago

> You really don't need a package manager for Go. "You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement. I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core development team has made it unclear whether they would even accept some of these features. I get that compilation performance is a high priority, but they've missed the big picture, that developer time also matters. The following exemplifies the problem: > Note that because Go is a compiled language, the only time versioning comes into play is a development time. Oh, that won't affect me at all; development time is only like 90% of the life of a project.

jerf 12y ago
The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inability to have a sensible discussion about generics within the community due to the near inability to have a sensible discussion about generics outside of the community. It isn't all necessarily hunky-dory. But if you haven't used Go, which is what it sounds like to me, you don't understand the current situation's cost/benefit analysis and are unlikely to be able to "just" "solve" the community's "problems" without such an understanding. Step 1 of any engineering effort is identify the problem, and it can never be skipped, no matter how sure you are you can this time. If you're not a Go user, you've skipped this step. Of course you're free to A: not be a Go user for any reason you choose and B: say whatever you like about Go from the outside. And I really mean that, quite deeply, not merely as a rhetorical flourish. There's too many languages to become expert in them all and we all must choose carefully according to our own knowledge and desires. My only point here is only that you shouldn't expect the community to be enthralled with the resulting commentary.
- copsarebastards 12y ago

tveita 12y ago

I would classify godep as a package manager in the same vein as bundler, pip, npm, etc., and in my experience it is absolutely essential if you still want your Go code to compile a month after you wrote it. I think the bit about source versus binary deployment is a bit of a red herring. It's not like any true Scotsman is deploying by running pip update in production either. As a developer you want to have code that compiles at all times. Having a binary you can't reproduce or change isn't going to be much comfort. If you're going to use third party libraries there is no reliable way to judge the stability of either the libraries you use directly or all your transitive dependencies. Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. Dependency management is not optional, but unfortunately Go makes it easy to hurt yourself by providing climbing holds without a safety harness. It isn't obvious to new programmers that they should use godep before they come back to an older project and it won't compile anymore.

NateDad 12y ago
>Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. I'm not sure what you mean by "conflict". That's the nice thing about the way go packages work. There's no v1 of a package and v2 of a package. All packages are different. If one dependency uses foo.v1 and one uses foo.v2 ... they don't conflict. They're as different to go as foo.v1 and bar.v1. >Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile. Again, this just doesn't happen. A dependency has one canonical location. If the code changes at that location, it changes for anyone that uses that code. Yes, it's possible this could break only part of your code, if only part of your code was relying on the old behavior/API... but that should be rare (and if it happens, it means you can't trust that third party to stay stable). I think most people who complain about Go lacking versioning of packages are still stuck in the mindset of pip, npm, etc, where versions are fungible, and your code doesn't know exactly what version it might be working against. This is just not the way Go works. There's one and only one version of a dependency that your project sees. Anyone using that dependency uses the same version. If the dependency's code compiles on its own, it'll compile on your machine, too.

orkoden 12y ago

An example for a dependency management package manager for a compiled language is [cocoa pods](http://cocoapods.org http://cocoapods.org) for Objective-C. It's really popular with iOS and OS X developers. Or look at [cabal](https://www.haskell.org/cabal/ https://www.haskell.org/cabal/) for Haskell. It's a package manager that doubles as build system. It helps when you use external open source projects and want to update it to a new version. With go you have to keep track of you external dependencies and their versions on your own.

pjmlp 12y ago
Just to extend your list. dub for D, http://code.dlang.org/ http://code.dlang.org/ cargo for Rust, https://crates.io/ https://crates.io/ biicode for C and C++, https://www.biicode.com/ https://www.biicode.com/ NuGet for C and C++, http://docs.nuget.org/consume/support-for-native-projects http://docs.nuget.org/consume/support-for-native-projects OPAM for OCaml, https://opam.ocaml.org/ https://opam.ocaml.org/

theseoafs 12y ago

So the "solution" to Go's package management is just statically linking every library you use?

EugeneOZ 12y ago

You really need to look at Cargo in rustlang to see what good package manager can do and how it improves development.

EugeneOZ 12y ago

Please somebody explain me how to manage next situation without manual copying of code and forking repos (in other words, we need to still be able get updates for minor versions from repositories). GOROOT/ pkg src/ lib1 app1 app2 And app1 requires lib1 version 3.x, app2 requires lib1 version 1.x. What can we do? Also, on whole this page https://golang.org/cmd/go/ https://golang.org/cmd/go/ I can't find ANY info, about how to fetch exact version from repo, not the master branch. In Go world all master branches are for stable code only, not for development? And all tools have only one version?

NateDad 12y ago
There's no such thing as lib1 version 3.x. lib1 is a single version. Every import path is a unique package. If you want to make a new version of lib1, you need to give it a different path. This can be as easy as manually inserting "v2" in the path, like /lib1/v2/ or /v2/lib1/ There's no way to use "go get" to get anything other than the head of the master branch... at least, not by default. If you use a service like http://gopkg.in http://gopkg.in then you can encode a version in the url/import path which can then redirect to a branch in github, so for example import "gopkg.in/natefinch/lumberjack.v2" will get the v2 branch of github.com/natefinch/lumberjack (gopkg.in does this with some git magic)
- EugeneOZ 12y ago
  > There's no such thing as lib1 version 3.x. lib1 is a single version. I don't agree with this part (or we are talking about different things), but thanks for the second part of reply. At least something :)