- Brecht
- Nov 7, 2009
-
|
Everyone wants a "go get"-able repo, but that's not the best way to manage a large project. IIRC this is at least part of what killed that Haunts game: they had external dependencies, and then all of a sudden github.com/dickhole/poo is gone because dickhole decided to delete his repo, or maybe he just completely changed the API and now your code doesn't build anymore.
We've started managing our Go code similarly to a well-run C project: You have a src/ directory under your top-level which includes subdirectories for your code AND for the external libraries you need. There's a script at the top level which sets GOPATH to the current directory and builds your code, compiling the dependencies in the process. This keeps you safe from dickhole deleting his repository, and it lets you adapt to an updated API on your own schedule, not at 4 p.m. on a Friday when dickhole decides to push his changes. When you're ready to update your library dependencies, you just check out the latest version of their repo, copy it in, make sure it builds, and commit.
Vendoring your deps and keeping your repo go-gettable aren't mutually exclusive. Your repo shouldn't represent its own GOPATH.
|
#
¿
Jul 28, 2014 23:38
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
#
¿
Apr 29, 2024 03:41
|
|
- Brecht
- Nov 7, 2009
-
|
Forking the repos you depend on is called vendoring, and it works fine. Great, even.
http://github.com/tools/godep
|
#
¿
Oct 2, 2014 02:03
|
|