Hacker News new | ask | show | jobs
by supersillyus 5133 days ago
It is quite neat and mighty convenient, but I sorta live in fear that at some arbitrary point the library will change and my code will just stop working. I konw this isn't a problem unique to Go and there are solutions, but the lack of explicit versioning makes me nervous. Then again, it hasn't bit me yet, and I certainly have benefitted from the ease.
5 comments
krakensden 5133 days ago
I think it works out pretty well- if you're working on a Very Serious Project(TM), you point it at a URL that's your project's closely managed fork.
link
zemo 5133 days ago
it doesn't "compile from a url", the package name is just the url address. You still have a directory of downloaded packages analogous to Python's site-packages, and they don't update unless you explicitly update them. The difference is that if you say `go get github.com/whatever/foo` the package source will be downloaded to a location such as `/usr/local/go/src/pkg/github.com/whatever/foo`.
link
jemeshsu 5133 days ago
One solution is to add version to url. Some examples from Google API for Golang (http://code.google.com/p/google-api-go-client/): code.google.com/p/google-api-go-client/tasks/v1 code.google.com/p/google-api-go-client/books/v1
link
technomancy 5133 days ago
This is absolutely the only right way to do this. It's very unsettling that locking to a specific revision isn't considered the default.

Depending on git master is cowboy coding at its most cavalier; build systems should prize repeatability above all else.

link
_ak 5133 days ago
If you'r really worried about code changes that might break your project, you're free to fork the library, e.g. if it's on GitHub. Even though that's not really a sophisticated way of versioning, it's quite convenient.
link
drivebyacct2 5133 days ago
There are a few things that can be done:

1. Hope that the projects you depend on have a tag that you can reference as your import or that you can acquire specifically with `go get`

2. Fork them and keep track of them yourself.

3. Use the tool (I can't find the link) that manages version dependencies per-project so that you can have different versions for different projects based on your needs (think virutalenv).

link