1 00:00:01,500 --> 00:00:05,700 Unless you write absolutely all your code yourself, you end up importing 2 00:00:05,700 --> 00:00:09,800 packages from other people probably using go get and getting them 3 00:00:09,800 --> 00:00:13,900 from GitHub or code.google.com or other places. And 4 00:00:13,900 --> 00:00:17,500 this leads to a problem which is how do you decide, which 5 00:00:17,500 --> 00:00:21,400 instance of an external package? Are you using? How do you keep it up to 6 00:00:21,400 --> 00:00:24,700 date? What do you include in your Source tree Etc? 7 00:00:25,800 --> 00:00:29,200 Within go, you obviously, you have the go path which defines a 8 00:00:29,200 --> 00:00:33,900 workspace and within a workspace, you might typically have a single 9 00:00:33,900 --> 00:00:37,700 copy of something say that you got from GitHub. If you have many different 10 00:00:37,700 --> 00:00:41,700 programs, bill from the same workspace, then you may end up wanting to have different versions of 11 00:00:41,700 --> 00:00:45,400 those external dependencies and it becomes a bit difficult to do that 12 00:00:45,800 --> 00:00:49,900 and there'll be various hacks. People have done over time where they've gone in and kept 13 00:00:49,900 --> 00:00:53,900 copies and different parts of their tree, even change the names and things like that to try and keep 14 00:00:53,900 --> 00:00:54,500 up to date. 15 00:00:56,000 --> 00:01:00,900 The real approach. This is actually being in some way solved in, go 1.5. And you do 16 00:01:00,900 --> 00:01:04,300 want to have go 1.5 for many reasons garbage 17 00:01:04,300 --> 00:01:08,800 collection that. It's the latest version of the compiler, which in go, 18 00:01:09,100 --> 00:01:12,200 but also because of something called the vendor experiment. 19 00:01:13,200 --> 00:01:17,800 If the term vendoring is unfamiliar to you, what it really means is making a 20 00:01:17,800 --> 00:01:21,800 copy of someone else's code, into your Source tree and keeping it up-to-date. 21 00:01:22,600 --> 00:01:26,100 And what the go authors have decide to do is make this very 22 00:01:26,100 --> 00:01:30,900 explicit with Ingo Itself by having a directory called vendor 23 00:01:31,800 --> 00:01:35,500 now to make this work so that different parts of your package 24 00:01:35,600 --> 00:01:39,600 packages can have different versions of a particular package taken in from the outside. 25 00:01:40,200 --> 00:01:42,700 They've actually specified a very standard way of doing. 26 00:01:42,900 --> 00:01:46,700 This within the standard trees and I'm going to just talk about this a little bit, 27 00:01:46,700 --> 00:01:50,900 using the documentation from the golang website. So if you look at 28 00:01:50,900 --> 00:01:54,900 the latest version of the go command, 415, you'll find a 29 00:01:54,900 --> 00:01:58,700 section called vendor directories and there's actually an 30 00:01:58,700 --> 00:02:02,500 environment variable, you can set called go 1/5, vendor 31 00:02:02,500 --> 00:02:06,900 experiment, which will enable this. And they give an example here, which 32 00:02:06,900 --> 00:02:10,700 kind of makes clear what happens. So if I take a look at this 33 00:02:10,700 --> 00:02:12,700 example workspace here, 34 00:02:12,900 --> 00:02:16,500 Here, you'll see. So this would be this particular person's, gopath 35 00:02:16,500 --> 00:02:20,800 directory, and here's the sauce and underneath, you have source and you'll notice 36 00:02:20,800 --> 00:02:24,900 that there's actually a directory called vendor. And now what go 37 00:02:24,900 --> 00:02:28,800 does is it takes a directory called vendor and treats it in a very special 38 00:02:28,800 --> 00:02:31,800 manner. If the vendor experiment is enabled 39 00:02:32,500 --> 00:02:36,800 underneath, the vendor is something that's been imported more typical. This might say something like 40 00:02:36,800 --> 00:02:40,900 github.com / program, C, / a particular package, 41 00:02:40,900 --> 00:02:42,800 that's being imported, but it 42 00:02:42,900 --> 00:02:46,800 And any other sort of code path. The important thing is when the vendor 43 00:02:46,800 --> 00:02:50,700 experiment is enabled, when you're importing 44 00:02:50,700 --> 00:02:53,800 this, you would import it using this part, 45 00:02:54,400 --> 00:02:58,900 not the whole path down to there. So it essentially creates a 46 00:02:58,900 --> 00:03:02,500 kind of new route within the directory charge where you can find things. So you'd be 47 00:03:02,500 --> 00:03:06,900 importing GitHub /, / MC /, whatever, and that would 48 00:03:06,900 --> 00:03:10,800 work. The other thing is that it disambiguates if you had multiple 49 00:03:10,800 --> 00:03:12,300 copies of it within 50 00:03:12,900 --> 00:03:16,700 The tree structure by the fact that you can only do that 51 00:03:16,700 --> 00:03:20,300 import using this particular code within the Parent 52 00:03:20,300 --> 00:03:24,600 Directory context. So Foo here can 53 00:03:24,600 --> 00:03:28,900 import crash bang but something else at the same level would not be 54 00:03:28,900 --> 00:03:32,600 able to. It's not allowed to because it's not part of 55 00:03:32,600 --> 00:03:36,900 that tree and that allows you to keep a copy of someone else's code in your tree, 56 00:03:36,900 --> 00:03:40,200 keep it up to date for a particular package or set of packages 57 00:03:40,800 --> 00:03:42,700 without having a clash with another part of the 58 00:03:42,900 --> 00:03:46,600 Me now is a fairly simple thing and is based on these directory 59 00:03:46,600 --> 00:03:50,400 names. But I think it is a very good approach. And all those labels is an 60 00:03:50,400 --> 00:03:54,800 experiment right now. It looks like it has quite a lot of acceptance, and I think we'll find 61 00:03:54,800 --> 00:03:58,800 people using this more and more. Of course, this thing could actually be a 62 00:03:58,800 --> 00:04:02,500 get some module for example, that you might update using 63 00:04:02,600 --> 00:04:06,900 normal sub-module methods, or it might just be a copy of the code, that's been copied into the tree 64 00:04:06,900 --> 00:04:10,500 itself. Either way, this gives you a simple way of having someone's 65 00:04:10,500 --> 00:04:12,100 external code in an unambiguous 66 00:04:12,800 --> 00:04:14,700 Ian, inside your go tree.