{"id":20285434,"url":"https://github.com/mramshaw/vgo","last_synced_at":"2025-10-12T12:25:04.020Z","repository":{"id":92906641,"uuid":"147369255","full_name":"mramshaw/vgo","owner":"mramshaw","description":"Getting familiar with vgo, the latest Golang package manager.","archived":false,"fork":false,"pushed_at":"2019-08-02T21:52:34.000Z","size":10754,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-07-01T08:04:52.249Z","etag":null,"topics":["dependencies","dependency-manager","go","golang","golang-tools","vgo"],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mramshaw.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-09-04T15:39:54.000Z","updated_at":"2019-08-02T21:52:36.000Z","dependencies_parsed_at":"2023-04-25T17:02:15.545Z","dependency_job_id":null,"html_url":"https://github.com/mramshaw/vgo","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/mramshaw/vgo","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mramshaw%2Fvgo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mramshaw%2Fvgo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mramshaw%2Fvgo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mramshaw%2Fvgo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mramshaw","download_url":"https://codeload.github.com/mramshaw/vgo/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mramshaw%2Fvgo/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":264394670,"owners_count":23601344,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dependencies","dependency-manager","go","golang","golang-tools","vgo"],"created_at":"2024-11-14T14:26:41.029Z","updated_at":"2025-10-12T12:24:58.984Z","avatar_url":"https://github.com/mramshaw.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# vgo\n\n![Go_Logo](/images/Go_Logo_Aqua.svg)\n\nGetting familiar with [vgo](http://github.com/golang/vgo/), the latest Golang package manager.\n\n[In the go community `vgo` is also known as [go modules](http://github.com/golang/go/wiki/Modules).\n Older package managers include [dep](http://golang.github.io/dep/) and [glide](http://glide.sh).]\n\nProbably the place to start is with Russ Cox's blog:\n\n    http://research.swtch.com/vgo-tour\n\n[UPDATE: `vgo` was released with Go 1.11 while Russ Cox's post refers to an earlier implementation.\nThere are substantial differences, so Russ Cox's blog should only be read for an overview\nand not considered to be authoritative. As well, `vgo` does not seem to follow standard \\*nix\nconventions for command-line tools (perhaps this will change in the future).]\n\n## Contents\n\n- [Rationale](#rationale)\n- [Requirements](#requirements)\n- [To Install](#to-install)\n- [To Remove](#to-remove)\n- [To Use](#to-use)\n- [Git](#git)\n- [Caches](#caches)\n    - [Build cache](#build-cache)\n    - [Module cache](#module-cache)\n- [Dependencies](#dependencies)\n    - [Vendoring Dependencies](#vendoring-dependencies)\n    - [Updating Dependencies](#updating-dependencies)\n- [GO111MODULE](#go111module)\n- [My recommended workflow](#my-recommended-workflow)\n    - [Step 1](#step-1)\n    - [Step 2](#step-2)\n    - [Step 3](#step-3)\n- [go mod edit](#go-mod-edit)\n- [Travis CI](#travis-ci)\n- [Dependency Scanning](#dependency-scanning)\n- [Cloud Functions](#cloud-functions)\n- [Reference](#reference)\n- [To Do](#to-do)\n\n## Rationale\n\nDependency management in Golang has always been tricky. The original developers flagged\nit as TBD and it's been problematic ever since. Building upon successful package managers\nsuch as `Composer`, `npm`, and `pip` the Golang team came up with `vgo` - which uses a lot\nof best practices.\n\nNot everyone is happy about it though; for a useful recap of package management in Go\nthe following blog post is worth a read:\n\n    http://codeengineered.com/blog/2018/golang-godep-to-vgo/\n\n\u003e vgo was built when the Go lead at Google went off on his own to build a solution.\n\nSam Boyer and the `dep` team do not sound happy either:\n\n    https://golang.github.io/dep/blog/2018/07/25/announce-v0.5.0.html\n\n\u003e That means there's no choosing between \"vgo/modules or dep.\" It'll be \"vgo, or another language.\"\n\nAs `dep` is still being actively maintained, I think if I was using `dep` I would stick\nwith it until there was a compelling reason to switch to `vgo`.\n\nMy personal feeling is that - while I understand the attraction of a central dependency\nstore - dependencies should be bundled with the code that depends on them (links can go\ndead and sometimes locating dependencies can be a trial). So I am not a fan of caching\ndownloaded modules centrally - or even caching build results centrally. I like to be\nin control and am not a fan of having to locate hidden caches just so that I can nuke\nthem in order to get a 'clean' build. I would prefer that this should be under developer\ncontrol - and more transparent.\n\n[This is a use case for `go mod vendor`, see [Vendoring Dependencies](#vendoring-dependencies)\n below for more details.]\n\nI will use the `main.go` file from my [UI repo](http://github.com/mramshaw/ui) for testing.\n\n[The dependencies for this are tricky so it is a good initial test.]\n\n## Requirements\n\n* a recent version of Golang (preferably a released version such as 1.11 or greater)\n\n## To Install\n\nThe command to run to install `vgo`:\n\n    $ go get -u golang.org/x/vgo\n\n[UPDATE: `vgo` was the pre-release version - with 1.11 the new behaviour is activated\n by specifying `GO111MODULE=on` prior to the `go` command - as can be seen below.\n Presumably with later releases this will become the default option.]\n\n## To Remove\n\nAs `vgo` is no longer required with Golang 1.11 (and later) it may be removed.\n\nThe command to run to remove `vgo`:\n\n    $ go clean -i golang.org/x/vgo\n\nThis will leave some cruft in the various Go build and test caches, which\nseems to be consistent with most of the other package managers (such as\n`npm` et al). In practice, the normal procedure seems to be to either delete\nthe caches when disk space is needed or else to virtualize the build process\n(by using either `docker` or `vagrant`).\n\nFor a dry run of the above command:\n\n    $ go clean -n -i golang.org/x/vgo\n\nAs noted above, this will still leave some remaining cruft which may be cleaned\nup manually.\n\nUPDATE: It seems that specifying `GO111MODULE=on` installs `vgo` as a dependency,\nwhich feels like a bit of a bodge. Perhaps this will be eliminated with later\nversions of Go.\n\nPresumably the build and test caches can be cleaned out as follows:\n\n    $ go clean -cache -testcache -modcache\n\n[Add an `-x` option to see the remove commands as they are executed.]\n\nAt least with `npm` it is possible to define build and runtime dependencies.\n\nIt would be nice if `vgo` had this level of flexibility.\n\n## To Use\n\nThe command to run to build the project:\n\n    $ GO111MODULE=on go build\n\nThis builds a binary called `vgo` (not really what we want), so:\n\n    $ GO111MODULE=on go build -o greeting\n\nWe can execute this as follows:\n\n    $ ./greeting\n\nAnd everything works as expected. Huzzah!\n\n## Git\n\nThe build generates `go.mod` and `go.sum` files. These should be checked into the Git repo.\n\nOr perhaps not ... Dave Cheney has some interesting things to say:\n\n    http://dave.cheney.net/2018/07/14/taking-go-modules-for-a-spin\n\nAnd:\n\n    http://dave.cheney.net/2018/07/16/using-go-modules-with-travis-ci\n\n[This last post is pretty interesting as it focuses on Travis integration. By default\nGo will continue to use pre-1.11 build behaviour unless `GO111MODULE=on` is specified.\nSo it seems that modules are a build-breaking issue. I wonder how this squares with the\n[Go 1 Compatibility idea](https://golang.org/doc/go1compat)?]\n\n## Caches\n\nDave Cheney's blog post has a useful note from Russ Cox about caches.\n\nRecent versions of Go have introduced caches, both of __test__ results and __build__ results.\n\nThese probably correspond to the `-testcache` and `-cache` options for `go clean`.\n\nThe new cache seems to correspond with the `-modcache` option for `go clean`.\n\n#### Build cache\n\n\u003e The build cache ($GOCACHE, defaulting to $HOME/.cache/go-build) is for storing recent compilation results\n\nLets have a look at it:\n\n```bash\n$ cat ~/.cache/go-build/README\nThis directory holds cached build artifacts from the Go build system.\nRun \"go clean -cache\" if the directory is getting too large.\nSee golang.org to learn more about Go.\n$\n```\n\n#### Module cache\n\n\u003e The module cache ($GOPATH/src/mod, defaulting to $HOME/go/src/mod) is for storing downloaded source code\n\nThis folder does not exist on my computer, I suspect it is actually the following:\n\n```bash\n$ ls -al ~/go/pkg/mod/cache\ntotal 16\ndrwxrwxr-x 4 owner owner 4096 Oct 12 11:36 .\ndrwxrwxr-x 6 owner owner 4096 Oct 13 15:48 ..\ndrwxrwxr-x 5 owner owner 4096 Oct 13 15:48 download\ndrwxrwxr-x 9 owner owner 4096 Oct 13 15:48 vcs\n$\n```\n\n## Dependencies\n\nThe following command will create `go.mod` and `go.sum` files:\n\n    $ GO111MODULE=on go build -o greeting\n\nHowever, under some circumstances it may be necessary to first specify the package:\n\n    $ go mod init github.com/mramshaw/vgo\n\n[This will create a `go.mod` file - the `go.sum` file will be created by a build.]\n\n#### Vendoring Dependencies\n\nThe `go mod vendor` command will populate the required dependencies.\n\n```bash\n$ go mod vendor\ngo: finding github.com/andlabs/ui latest\n$\n```\n\n[It may be first necessary to specify the package (as above) via `go mod init`.]\n\nSome useful help:\n\n```bash\n$ go mod help vendor\nusage: go mod vendor [-v]\n\nVendor resets the main module's vendor directory to include all packages\nneeded to build and test all the main module's packages.\nIt does not include test code for vendored packages.\n\nThe -v flag causes vendor to print the names of vendored\nmodules and packages to standard error.\n$\n```\n\n__Nota bene__: \"It does not include test code for vendored packages.\"\n\n#### Updating Dependencies\n\nInterestingly, `vgo` uses a fairly conservative approach to dependencies. It uses the lowest\npossible version number - as opposed to the ___latest___ version number.\n\nTo list the current modules:\n\n    $ GO111MODULE=on go list -m\n\nTo update (as in, check for more recent versions of) the current modules:\n\n    $ GO111MODULE=on go list -m -u\n\nThere is also `go mod tidy`:\n\n```bash\n$ go mod help tidy\nusage: go mod tidy [-v]\n\nTidy makes sure go.mod matches the source code in the module.\nIt adds any missing modules necessary to build the current module's\npackages and dependencies, and it removes unused modules that\ndon't provide any relevant packages. It also adds any missing entries\nto go.sum and removes any unnecessary ones.\n\nThe -v flag causes tidy to print information about removed modules\nto standard error.\n$\n```\n\nBy default `go mod tidy` produces no output. It's worth noting that it will not clean up\nany vendored dependencies either (these must be deleted manually as `go mod vendor` does\nnot have a removal option - the simplest option is to delete the `vendor` folder and then\nre-create it with `go mod vendor`).\n\n## GO111MODULE\n\nIt seems that the presence of a `go.mod` file implies `GO111MODULE=on` so that if\n[my recommended workflow](#my-recommended-workflow) is followed, there is no need\nto explicitly use `GO111MODULE=on`.\n\nUPDATE: With Go __1.12__ this defaults to __auto__, which means that it will be\nused if there is a __go.mod__ file available and will not be used if there isn't.\n\n__NOTA BENE:__ the __auto__ setting will prevent the use of modules in the $GOPATH/src directory.\n\n[This is fine by me but may affect ___your___ workflow.]\n\n## My recommended workflow\n\nThis may evolve over time, but for the moment it is as follows:\n\n1. go mod init ...\n2. go mod vendor -v\n3. go build ...\n\n#### Step 1\n\nFor step 1, best results will be had by specifying the fully-qualified package name, i.e.:\n\n    $ go mod init github.com/xxxx/yyyy\n\ninstead of:\n\n    $ go mod init yyyy\n\n[This will result in a cleaner dependency graph.]\n\n#### Step 2\n\nThis will vendor the dependencies in the local file system, instead of in a central cache.\n\n[Which is ___my___ preference.]\n\n#### Step 3\n\nStep 3 could just as easily be `go run ...` or `go test ...` or `make` or whatever.\n\n## go mod edit\n\nAt present (as of Go 1.11) it seems that `go mod edit ...` does not work as expected.\n\nA workaround is to use `sed` to edit the `go.mod` file instead.\n\n[Remember to re-run `go mod vendor` after editing the `go.mod` file.]\n\n## Travis CI\n\nThere are some great tips from Dave Cheney, my experience was that one of the following\nwill be needed to get Travis to build properly:\n\n```\nscript:\n  - env GO111MODULE=on go build\n  - env GO111MODULE=on go test\n```\n\n[Individual environment variables]\n\nOr else a global environment variable:\n\n```\nenv:\n  global:\n  - GO111MODULE=on\n```\n\n[This last worked for me]\n\n## Dependency Scanning\n\nMy initial motivation for this repo was to try out Snyk's vulnerability scanning. However,\nas of this writing (September 2018) Snyk does not yet support `vgo`:\n\n    http://support.snyk.io/hc/en-us/articles/360000911957-Language-support\n\n[Snyk does support `dep` via `Gopkg.lock` scanning however.]\n\n## Cloud Functions\n\nPerhaps not surprisingly, Google's Cloud Functions support `vgo` for Go:\n\n    http://cloud.google.com/functions/docs/writing/specifying-dependencies-go\n\nThe article recommends the following workflow:\n\n    export GO111MODULE=on\n    go mod init\n    go mod tidy\n\n[From the above page, assuming you are within the $GOPATH.]\n\n## Reference\n\nProbably the best place to read up on `vgo` (also known as ___go modules___):\n\n    http://github.com/golang/go/wiki/Modules\n\n## To Do\n\n- [x] Install latest Golang (1.12 as of May 2019)\n- [x] Investigate the use of `GO111MODULE=on`\n- [x] Investigate the removal of `vgo` via `go clean`\n- [x] Investigate `vgo` dependency via the use of `GO111MODULE=on`\n- [x] Investigate `go mod vendor` to deal with dependencies\n- [x] Investigate `go mod tidy` to deal with dependencies\n- [ ] Verify dependency migration via `go mod -init`\n- [x] Investigate Dave Cheney's thoughts\n- [x] Add notes on Travis CI integration\n- [ ] More testing\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmramshaw%2Fvgo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmramshaw%2Fvgo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmramshaw%2Fvgo/lists"}