-3

Approach 1

For any application project structure, an author recommends below application project structure:

    Application

    ├── cmd/
    ├── internal/
    │   └── platform/
    └── vendor/

where vendor/ folder has 3rd party libraries within project structure, which are mostly go get'ble, but pushed to GitHub repo(in above case). Pushing /vendor folder to GitHub repo looks unnecessary

Approach 2

I generally go get 3rd party into common local workspace folder(~/golib), which is outside project structure, and driven by GOPATH setting shown below. So, the code related to 3rd party is not pushed to GitHub:

export GOPATH=/home/user/golib
export PATH=$PATH:$GOPATH/bin
# First segment of GOPATH is used by "go get" command
# All segments of GOPATH are used for source code
export GOPATH=$GOPATH:/home/user/code

In approach 1, What is the advantage of maintaining vendor/ folder for 3rd party, within application project structure and push to GitHub repo? unlike approach 2

overexchange
  • 15,768
  • 30
  • 152
  • 347

2 Answers2

2

Support for vendor folder was added in Go 1.6 to help you get the version of the package you know works with your code, in case non-backward-compatible changes are made and you can't work out which revision in the repo is the one you used (or for the worse case that the repo disappears altogether).

The vendor folder approach is obviated by the use of modules added in recent Go releases, which allow you to get reproducible builds by guaranteeing the same versions of packages are used. Go Modules is similar to your Approach 2 but has better support in the Go compiler and tools.

In summary: your approach should be to use Go 1.14 with modules.

Andrew W. Phillips
  • 3,254
  • 1
  • 21
  • 24
0

IMHO

approach 1 my reasonable if you dont want every package that u use include certain package that apply in some go project fill up your storage disk, just common package that get installed globally

approach 2 is like the opposite from appproach 1 where you store everything inside local disk, but this way may have advantage if you want to build docker image so instead re download every image build, you can just take existing library in you local computer

protrafree
  • 96
  • 10