top | item 4013907

(no title)

supersillyus | 13 years 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.

discuss

order

krakensden|13 years 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.

zemo|13 years 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`.

jemeshsu|13 years 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

technomancy|13 years 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.

_ak|13 years 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.

drivebyacct2|13 years 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).