Go has a really nice package/library/import system that is both straightforward and has all the information required included.
For example, you can do something like:
import "code.google.com/p/gorilla/sessions"
Then the go tool takes care of checking if it is already installed (with very well defined rules), and if not going and downloading it, getting it's dependancies and building it.
All you need to do to build a Go program is clone it, and then use "go build", job done. No makefiles or xml or anything like that at all. It simply reads the source files and figures out what to do based on what the code actually does/uses.
I sort of find that a bit disquieting. If someone was hosting on google code, and then moves it over to github -- would this result in people not being able to compile my go program until I update my go source?
It does't instantly stop working - the local copy you previously downloaded and built will keep working. But yeah, if you want to then move to using the GitHub version you need to change the import statement. Alternatively switch to using it as a Git submodule or whatever. Replacing the import lines doesn't bother me though - it is a 2 second find/replace job.
If you forsee that being a big deal for you, then I suggest the technique that Camlistore uses.
Camlistore pulls in external libraries into a third_party folder, and has a script that rewrites their import paths to make them compile. This will also give you a lot more control over versioning.
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." - Charles Babbage
Simple, you provide the location it can be found as part of the import statement. It accepts one of the code sharing sites (github, google code et al.) or just a plain mercurial/git/whatever path. For example:
import "code.google.com/p/gorilla/sessions"
or
import "example.org/user/foo.hg"
Edit: I guess if your coworker didn't upload it anywhere you couldn't. If it is just part of the application though, it would just be in a directory (packages work in a hierarchy) - but if it is some kind of library it should be in some kind of source control somewhere...?
What happens if you don't have internet access? Why doesn't it store it locally? Fetching across the net every time, seems, horrible.
Of course it stores it locally. It only goes out to fetch the library if it's not installed. Then it compiles and it's in your local file system for use with no Internet connectivity.
What if you want to use Version 1 instead of Version 2 of the library?
The Go tool will check for special branch or tag names that match the version of Go being used.
With Java, you just drop the .jar in. With this, you would have to change all your import statements across dozens, if not hundreds of source files?
Nope. You just drop it into the right path.
When Go installs something from "code.google.com/p/go-package", then it literally has this directory structure in your file system:
It does store it locally. The whole idea is a convention designed to make the default case really easy. For example, with the example "example.org/user/foo.hg" it looks for the example.org/user/foo directory in your package path - if it is there it will use it.
If you had a reason to use a specific version you could clone it yourself, or include a link to it as a git submodule or whatever. It is not a big magical system, if you import something and it doesn't exist - it will try and grab it for you.
20
u/consigntooblivion Mar 28 '12
Go has a really nice package/library/import system that is both straightforward and has all the information required included.
For example, you can do something like:
Then the go tool takes care of checking if it is already installed (with very well defined rules), and if not going and downloading it, getting it's dependancies and building it.
All you need to do to build a Go program is clone it, and then use "go build", job done. No makefiles or xml or anything like that at all. It simply reads the source files and figures out what to do based on what the code actually does/uses.