Unless you write absolutely all your code yourself, you end up importing
packages from other people probably using go get and getting them
from GitHub or code.google.com or other places. And
this leads to a problem which is how do you decide, which
instance of an external package? Are you using? How do you keep it up to
date? What do you include in your Source tree Etc?
Within go, you obviously, you have the go path which defines a
workspace and within a workspace, you might typically have a single
copy of something say that you got from GitHub. If you have many different
programs, bill from the same workspace, then you may end up wanting to have different versions of
those external dependencies and it becomes a bit difficult to do that
and there'll be various hacks. People have done over time where they've gone in and kept
copies and different parts of their tree, even change the names and things like that to try and keep
up to date.
The real approach. This is actually being in some way solved in, go 1.5. And you do
want to have go 1.5 for many reasons garbage
collection that. It's the latest version of the compiler, which in go,
but also because of something called the vendor experiment.
If the term vendoring is unfamiliar to you, what it really means is making a
copy of someone else's code, into your Source tree and keeping it up-to-date.
And what the go authors have decide to do is make this very
explicit with Ingo Itself by having a directory called vendor
now to make this work so that different parts of your package
packages can have different versions of a particular package taken in from the outside.
They've actually specified a very standard way of doing.
This within the standard trees and I'm going to just talk about this a little bit,
using the documentation from the golang website. So if you look at
the latest version of the go command, 415, you'll find a
section called vendor directories and there's actually an
environment variable, you can set called go 1/5, vendor
experiment, which will enable this. And they give an example here, which
kind of makes clear what happens. So if I take a look at this
example workspace here,
Here, you'll see. So this would be this particular person's, gopath
directory, and here's the sauce and underneath, you have source and you'll notice
that there's actually a directory called vendor. And now what go
does is it takes a directory called vendor and treats it in a very special
manner. If the vendor experiment is enabled
underneath, the vendor is something that's been imported more typical. This might say something like
github.com / program, C, / a particular package,
that's being imported, but it
And any other sort of code path. The important thing is when the vendor
experiment is enabled, when you're importing
this, you would import it using this part,
not the whole path down to there. So it essentially creates a
kind of new route within the directory charge where you can find things. So you'd be
importing GitHub /, / MC /, whatever, and that would
work. The other thing is that it disambiguates if you had multiple
copies of it within
The tree structure by the fact that you can only do that
import using this particular code within the Parent
Directory context. So Foo here can
import crash bang but something else at the same level would not be
able to. It's not allowed to because it's not part of
that tree and that allows you to keep a copy of someone else's code in your tree,
keep it up to date for a particular package or set of packages
without having a clash with another part of the
Me now is a fairly simple thing and is based on these directory
names. But I think it is a very good approach. And all those labels is an
experiment right now. It looks like it has quite a lot of acceptance, and I think we'll find
people using this more and more. Of course, this thing could actually be a
get some module for example, that you might update using
normal sub-module methods, or it might just be a copy of the code, that's been copied into the tree
itself. Either way, this gives you a simple way of having someone's
external code in an unambiguous
Ian, inside your go tree.