On Sat, Nov 17, 2018 at 6:06 PM Robert Engels <reng...@ix.netcom.com> wrote:
> I think that is incorrect. The vendoring was a way to ensure certain > dependencies remained constant. The modules should eliminate that, barring > deletion of the source repo. > Even with modules, vendoring is still useful for situations where external network access is limited and the internal network does not yet have an Athena proxy to serve dependencies. Also, before modules keeping dependencies constant was achievable with glide, godeps, dep, etc, regarless of whether you choose to vendor it or not. But yes, vendoring made it so that your build would prefer that location over your GOPATH, and the module system provides a versioned cache now. I still like the idea of being able to vendor if that makes the most sense. > > On Nov 16, 2018, at 11:00 PM, Justin Israel <justinisr...@gmail.com> > wrote: > > > > On Sat, Nov 17, 2018 at 5:34 PM Henry <henry.adisuma...@gmail.com> wrote: > >> Hi, >> >> It seems to me that go modules and vendor attempt to solve the same >> problem. I wonder whether we should just choose one and scrap the other, or >> find a way to consolidate them under a single unified feature. >> > > Comparing "modules" and "vendoring" have only the most minor overlap. The > module system is a built-in way to describe and track dependencies. This > ultimately bakes down into a go.sum 'lock' file describing exactly what you > are using at a moment in time. The lock file can then be consulted in the > future to download those exact dependencies and reproduce the same build as > when it was originally written. Vendoring is a way to store dependency code > within the repo to avoid relying on downloading it again. It may or may not > store any information about the versions and it may or may not have been > done manually. The vendoring feature in the go module command is just a way > to store the dependencies from the go.sum solution within the repo and > avoid the download step. > > Why do you feel they are mutually exclusive? What if someone wants the > dependency management of modules and being able to avoid GOPATH, while also > wanting to avoid relying on a download process? > > >> I am a bit concerned with the direction Go is going. People keep adding >> stuffs into Go and later find themselves unable to remove existing features >> due to the backward compatibility promise. Go 1.11 is a different beast >> than Go 1.0, and is significantly more complex. >> >> I think Go2 is an opportunity to learn from Go1, and to start from a >> clean slate by scraping and consolidating features. Go2 needs to be simpler >> than Go1.11 >> >> Henry >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
