← Back to context

Comment by aston

12 years ago

"Golang dependency hell in Haunts The Manse game" is not only a very editorialized title for this link, but it's also factually incorrect. Here are some choice quotes about the codebase that have nothing to do with dependencies in Go:

Syntax errors:

  "Firstly, the source simply doesn't compile."

Performance problems:

   "...it's horribly slow."

Bad version control:

  "... the original code [has] ... potentially significant differences"

Those sorts of mistakes seem consistent with the type of coder who wouldn't set aside the 3 minutes it takes to understand Go's dependency system and either use it correctly or build a super-simple makefile to pull the correct versions of code from elsewhere.

Also, pedantic but worth noting: Golang is not the name of the language.

Golang should be the name of the language. Ironic that you can't Google for "go" and get relevant results, but "golang" works well.

I've got 3 minutes. I've spent more than 3 minutes searching, and I can't find a way to specify a version in an import (though you can tag the go version, you still can't tie the import to a specific tag or version or commit). Am I missing something? It seems the only way around this is to check out a point in time release and import that (which would solve the problem the article mentions). However, that's a workaround for a problem that package managers like NPM and RubyGems have trivially solved.

  • You can't. The right way to spend the 3 minutes is to read the docs. [1] [2]

    Also, just because it doesn't work the way NPM does doesn't mean it doesn't work.

    [1] http://golang.org/doc/code.html#remote

    [2] http://golang.org/cmd/go/#hdr-Remote_import_path_syntax (linked from [1])

    • Neither of those links address the issue the author mentioned, nor do they describe the need to use your own local copy of a package in case the package authors introduce non-backwards compatible changes. Yes, it needn't behave like NPM, or RubyGems, or Aptitude, or Homebrew, or any of the dozen or so systems out there for install remote packages that let you indicate version.

  • There is no version control for dependencies. You pretty much have to download the version you want manually, and then reference your local copy. Many people are aware of this and I imagine there will be work done to support versioning in some way.