1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
jamie [1:36 PM]
did you just pull down that go repo to work on?

russellbal [1:31 PM]
I cloned it with normal git, maybe I should have `go get` it?

jamie [1:32 PM]
it's ok to git clone it (and preferable if it's private), just make sure it's in $GOPATH/src/github.com/<github user>/<package>
(and if you're using a recent version of go, $GOPATH is ~/go) (edited)
when you `get get` a public repo, say `go get github.com/joe/biscuits`, it basically does a mkdir -p `$GOPATH/src/github.com/joe; cd $GOPATH/src/github.com/joe; git clone https://github.com/joe/biscuits.git`

russellbal [1:35 PM]
Ok

jamie [1:36 PM]
not sure if you guys use package managers, but the default dep resolution could also be done from that repo/package's directory by running `go get ./...`
recursively fetches all the deps and puts them in the respective $GOPATH/src/... paths

russellbal [1:36 PM]
You that's working.
Ok so like go sorta wants everything nested under a single root.

jamie [1:37 PM]
yeah

russellbal [1:37 PM]
I actually never knew that.

jamie [1:37 PM]
that's partly how it has the super fast compile times - reduces dupe work

russellbal [1:37 PM]
That should be like go101

jamie [1:37 PM]
heh it is somewhere
so re: compile time and how it relates to this structure
you might have the flavortown library at $GOPATH/src/github.com/guyfieri/flavortown
and two different apps that use it: $GOPATH/src/github.com/russ/app-a and app-b
when you run `go build github.com/russ/app-a` which uses flavortown, flavortown's source will be compiled in a path in $GOPATH/pkg/<arch>/...
when you do a `go build github.com/russ/app-b`, which also uses flavortown, it will skip recompiling
this is one of the huge workflow gains that c/cpp doesn't have

russellbal [1:42 PM]
What if you needed to upgrade only one app to latest flavortown? (edited)

jamie [1:42 PM]
vendoring is the easiest built in way
so say app-b wants the latest flavortown but it might break other apps
you leave app-b as is without rewriting the import paths or anything, create a vendor subdir in that project's path ( `$GOPATH/github.com/russ/app-b/vendor` ) then git clone the desired version to it ( `$GOPATH/github.com/russ/app-b/vendor/github.com/guyfieri/flavortown` ) (edited)
at build time during import resolution, go checks if each package happens to exist in the app being built's `vendor` directory, if so, it uses that version