Golang dependency hell in Haunts The Manse game

http://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre/posts/373466

by laurent123456 • 13 years ago

15 22 13 years ago

bentcorner• 13 years ago

Previous discussion: https://news.ycombinator.com/item?id=5707019

kristianp2• 13 years ago

And the March 5 update on the Kickstarter page seems to imply the project has been abandoned: http://www.kickstarter.com/projects/2066438441/haunts-the-ma...

aston2• 13 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.

bdcravens3• 13 years ago

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

bdcravens3• 13 years ago

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.

aston2• 13 years ago

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

kristianp2• 13 years ago

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.

crcsmnky• 13 years ago

"There is nothing special in Go that makes it particularly well suited to video games, but on the other hand there is nothing inherent in the language that makes it a bad choice, except for the fact that it's new and not well supported."

I would say that "new and not well supported" makes this a potentially bad choice for shipping code. Not to say that it can't be used but the problem with new technologies is that not all warts have been properly exposed and you can open yourself up to major headaches.

LPCRoy• 13 years ago

This has nothing to do with Go. It sounds like a case of poorly managed dependencies and build rules and likely weak engineering. The fact that they wanted to support the iPad and chose Go also shows this wasn't well thought out.

beatgammit• 13 years ago

I would say bad engineering:

* Go 1.0 had a terrible GC, especially on 32-bit platforms (their target platform)

* No manual memoray management (and unlikely to ever exist)

* Can't bind to C++, can't cross-compile cgo (gccgo can though)

Go is really cool, and I use it every day, but it doesn't make any sense for games, especially not for their target platform. Maybe in a few years the GC will be more reliable, but I wouldn't try to build a game in Go if I thought I might want to try to sell it.

MetaCosm5• 13 years ago

My summary from the last time it was posted.

"Original author didn't localize dependencies, obviously caused problems."

paulsamways4• 13 years ago

> and put import ("github.com/go-gl/opengl/gl") directly into your code. Viola! Thus hilarity ensues.

Of course it does! All they had to do is fork the project (which they have) and reference that it instead. Viola, problem solved!

MetaCosm5• 13 years ago

No need to fork, it puts a copy of those libraries under ./src, so you always have a sealed (hermetic) referentially complete copy.

You don't bet your production software on things randomly downloaded from the internet at compile time. This is why go never auto-updates when you do "go get", you have to explicitly use "go get -u".

Always localize what you depend on, you never know when a github repo could be pulled, go offline, be renamed, a lawsuit could break out making the library vanish. There are TONS of reasons you should ALWAYS localize your dependencies for building software.

EDIT: This has the amazingly cool side-effect of meaning even on complex projects, you can just do a git clone and then go build FOO and it just works, no nonsense, no fuss, and it is EXACTLY in the state it was when it was checked in -- no surprises.

paulsamways4• 13 years ago

> No need to fork, it puts a copy of those libraries under ./src, so you always have a sealed (hermetic) referentially complete copy.

While that is true, it doesn't solve the problem with distributed teams. The library path MUST be pointing to a 'localized' repository to solve the problem the Haunt guys are having.

EugeneOZ• 13 years ago

Sorry, but problem not in Go. Code of external libraries shouldn't be edited (or should be forked before changing).

NateDad• 13 years ago

"it makes a local copy of that external library. And if you have a local copy, you can edit it. And meanwhile, that person you copied the OpenGL code from? They are also changing their version (fixing bugs, adding features, adding bugs). Therefore there is no guarantee that your version and their version remain compatible: it takes work to maintain compatibility."

Remote packages in Go are like DLLs for other languages. Yes, if you edit a DLL locally, and other people download the public version of that DLL, they won't be the same. DON'T DO THAT.

Make your own copy of the public Go repository, so you can merge in changes from the main branch as you see fit. This is akin to making a copy of the DLL and using that to distribute with your code, rather than just telling people "go download the newest version of the DLL from github".

It's also good practice for go authors to keep any one repository backwards compatible, make it clear when the code is in flux and may have breaking changes... and to make new branches if they have to make significant changes to their code.

Golang dependency hell in Haunts The Manse game

Related Stories