Hacker News Reader

Comment by eddiezane | Hacker News Reader

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?

View on HN

> 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.

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.

> 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.

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.

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.

For a real dependency manager, look at Glide, I think it's nearly as good as Bundler: 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.

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).

Agreed, Go's strong standard library also helps avoid dependencies.

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.

What do you do when a dependency has a security problem? Or some other bug?

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.

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?

The tools essentially causes that to happen (its a bad thing). When someone installs your package (and you don't pin them somehow with something like godeps, path management, http://labix.org/gopkg.in, etc) you recursively retrieve the deps from some source at HEAD and that package is now updated for every other package using that GOPATH.

Oh, I misread the parent I replied to. I thought he was saying he downloads a copy of his dependencies and commits them to his repository without any tooling.

But he was only saying he uses the tools (which auto-update as your run them), and commits the result as a poor man's pinning arrangement.

Makes sense now. My questions are moot.

https://github.com/skelterjohn/wgo

Reply on news.ycombinator.com