go mod vendor will vendor all the .go files that are imported by your project (it is smart and only vendors the files actually used, not the whole repo for each import path). It keeps track of what is being vendored in vendor/modules.txt (not sure but I think this module list is only "for the humans" so that we can see in a diff what import paths have been added to vendor/)
To put things into vendor/, you first need to have modules turned on (go.mod at the root of your project) and then you can run go mod vendor once and here you go. Whenever you add import paths in your project, you also want to re-run go mod vendor to add/delete any missing/unused vendored files.
After having run go mod vendor you can fall back to using the good old GOPATH way (i.e. GO111MODULE=off) and not care about modules anymore.
Before Go 1.14, go build would by default use the modules in $GOPATH/pkg/mod instead of vendor/ and you had to run go build -mod=vendor
With Go 1.14 and above, the vendor/ folder is used by default and if you want to force using the $GOPATH/pkg/mod you can use go build -mod=mod.
Should I put my vendor/ in the GOPATH way or the go mod way
I think go mod vendor puts things in the GOPATH way (except it only puts the files that are "actually used"). Not sure I answered the question properly though 😞
Can I not put everything, but only a selectful of them that go get is failing to get?
Ah, right, I see the use case: you want to be able to manually add anything that go get doesn't know how to download (e.g. private networks, corporate firewalls).
I guess you can definitely do that: go mod vendor for anything that works and manually copy-paste the import paths that are failing. I guess you would have to update vendor/modules.txt too but not sure. The important part is that the hash of the files you manually add must match the hashes in the go.sum (I guess). 👍
Hi! Thanks for the kind words!!! 🙂
go mod vendorwill vendor all the .go files that are imported by your project (it is smart and only vendors the files actually used, not the whole repo for each import path). It keeps track of what is being vendored invendor/modules.txt(not sure but I think this module list is only "for the humans" so that we can see in a diff what import paths have been added tovendor/)vendor/, you first need to have modules turned on (go.modat the root of your project) and then you can rungo mod vendoronce and here you go. Whenever you add import paths in your project, you also want to re-rungo mod vendorto add/delete any missing/unused vendored files.go mod vendoryou can fall back to using the good oldGOPATHway (i.e.GO111MODULE=off) and not care about modules anymore.go buildwould by default use the modules in$GOPATH/pkg/modinstead ofvendor/and you had to rungo build -mod=vendorvendor/folder is used by default and if you want to force using the$GOPATH/pkg/modyou can usego build -mod=mod.I think
go mod vendorputs things in the GOPATH way (except it only puts the files that are "actually used"). Not sure I answered the question properly though 😞Ah, right, I see the use case: you want to be able to manually add anything that
go getdoesn't know how to download (e.g. private networks, corporate firewalls).I guess you can definitely do that:
go mod vendorfor anything that works and manually copy-paste the import paths that are failing. I guess you would have to updatevendor/modules.txttoo but not sure. The important part is that the hash of the files you manually add must match the hashes in thego.sum(I guess). 👍Thanks a lot for such detailed explanation.