4 ms·

I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm

I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes automatically without worrying about things breaking. How does the community feel this far along?

kasey_junk 11y ago
Dependency management is a huge weakness in golang and there isn't much point in debating it. That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).
- majormjr 11y ago
  Agreed, Go's strong standard library also helps avoid dependencies.
munificent 11y ago
> Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume. The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.
- prodigal_erik 11y ago
  Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.
  - munificent 11y ago
    > Use the platform's blessed solution (rpm or dpkg). Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or <random Linux distro> user, you don't get to use our language." Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you can, you just want have any users if you do.
    - conceit 11y ago
      But it makes sense if half the configuration (or what not you expect from a package) is platform specific, like where do the libraries and resources live, does pip know about the windows registry? I doubt it.
vidoc 11y ago
https://github.com/skelterjohn/wgo https://github.com/skelterjohn/wgo
lobster_johnson 11y ago
For a real dependency manager, look at Glide, I think it's nearly as good as Bundler: https://github.com/Masterminds/glide https://github.com/Masterminds/glide. It's not a package manager per se — Go doesn't have a package system with manifest files like RubyGems and NPM — but it does manage dependencies in the same way, with versioning constraints and lock files.
jimjimjim 11y ago
I've never really understood this general complaint about dependencies and go. Maybe it's my work environment? Either: i'm writing something quick and/or as a one-off in which case i just 'go get' anything i need. Or: It's 'full-enterprise' style where each third-party thing that gets used is checked and stored locally. The build is built against these stored versions. If an improvement is made to a 3rd party thing then the changes are reviewed and if suitable that new version is stored locally. If the older go release needs to be rebuilt or investigated it can be rebuilt with the earlier versions by the clean build system. Anything in-between wouldn't get passed QA. but obviously ymmv.
lopatin 11y ago
I agree that it's necessary to pin dependency versions down somehow. So I commit my Go dependencies into my project's version control. I heard Google does this internally too, but I can't confirm that. But I can say that I've had zero problems using this dependency approach for building web systems in Go. There's just something about the ecosystem of dependencies. Most of the deps I use are considered to be done. They are simple, small, and orthogonal to each other. Maybe it's because of the convention to make your library implement interfaces defined in the standard library. Maybe it's some kind of ingenious magical feedback loop where, since there is no package version manager, authors are encouraged to write once and then publish finished products instead working on overreaching and interconnected packages that get API changes every month. Therefore alleviating the need for a package version manager. My point is just that I wouldn't want people who are considering Go to immediately write it off because of the lack of a standard dep version manager. You can lock dependencies with godep. Or you can check in your dependencies to your project's source control. Either way, even though it's unconventional, it most likely won't be a problem.
- jjnoakes 11y ago
  What do you do when a dependency has a security problem? Or some other bug?
  - Goopplesoft 11y ago
    Its generally unlikely those things lead to interface changes. e.g. func bcrypt(salt string, password string). Generally the bug isn't in the interface. So its somewhat safe to upgrade the dep and see if the compiler complains Also exporting of interfaces is protected by case private()/Public() which leads to refined interfaces being exported. And the go vet tool expects all exported functions be documented. Not saying a package manager wouldn't be nice.
    - jjnoakes 11y ago
      This didn't directly answer my question, but it implies that you just periodically update all of your dependencies to the latest versions and pray your tests pass with minimal changes required. Yes?

kasey_junk 11y ago

Dependency management is a huge weakness in golang and there isn't much point in debating it. That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).

majormjr 11y ago
Agreed, Go's strong standard library also helps avoid dependencies.

munificent 11y ago

> Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume. The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.

prodigal_erik 11y ago
Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.
- munificent 11y ago
  > Use the platform's blessed solution (rpm or dpkg). Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or <random Linux distro> user, you don't get to use our language." Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you can, you just want have any users if you do.
  - conceit 11y ago
    But it makes sense if half the configuration (or what not you expect from a package) is platform specific, like where do the libraries and resources live, does pip know about the windows registry? I doubt it.

vidoc 11y ago

https://github.com/skelterjohn/wgo https://github.com/skelterjohn/wgo

lobster_johnson 11y ago

For a real dependency manager, look at Glide, I think it's nearly as good as Bundler: https://github.com/Masterminds/glide https://github.com/Masterminds/glide. It's not a package manager per se — Go doesn't have a package system with manifest files like RubyGems and NPM — but it does manage dependencies in the same way, with versioning constraints and lock files.

jimjimjim 11y ago

I've never really understood this general complaint about dependencies and go. Maybe it's my work environment? Either: i'm writing something quick and/or as a one-off in which case i just 'go get' anything i need. Or: It's 'full-enterprise' style where each third-party thing that gets used is checked and stored locally. The build is built against these stored versions. If an improvement is made to a 3rd party thing then the changes are reviewed and if suitable that new version is stored locally. If the older go release needs to be rebuilt or investigated it can be rebuilt with the earlier versions by the clean build system. Anything in-between wouldn't get passed QA. but obviously ymmv.

lopatin 11y ago

I agree that it's necessary to pin dependency versions down somehow. So I commit my Go dependencies into my project's version control. I heard Google does this internally too, but I can't confirm that. But I can say that I've had zero problems using this dependency approach for building web systems in Go. There's just something about the ecosystem of dependencies. Most of the deps I use are considered to be done. They are simple, small, and orthogonal to each other. Maybe it's because of the convention to make your library implement interfaces defined in the standard library. Maybe it's some kind of ingenious magical feedback loop where, since there is no package version manager, authors are encouraged to write once and then publish finished products instead working on overreaching and interconnected packages that get API changes every month. Therefore alleviating the need for a package version manager. My point is just that I wouldn't want people who are considering Go to immediately write it off because of the lack of a standard dep version manager. You can lock dependencies with godep. Or you can check in your dependencies to your project's source control. Either way, even though it's unconventional, it most likely won't be a problem.

jjnoakes 11y ago
What do you do when a dependency has a security problem? Or some other bug?
- Goopplesoft 11y ago
  Its generally unlikely those things lead to interface changes. e.g. func bcrypt(salt string, password string). Generally the bug isn't in the interface. So its somewhat safe to upgrade the dep and see if the compiler complains Also exporting of interfaces is protected by case private()/Public() which leads to refined interfaces being exported. And the go vet tool expects all exported functions be documented. Not saying a package manager wouldn't be nice.
  - jjnoakes 11y ago
    This didn't directly answer my question, but it implies that you just periodically update all of your dependencies to the latest versions and pray your tests pass with minimal changes required. Yes?