On Sat, Nov 17, 2018 at 6:15 PM Justin Israel <justinisr...@gmail.com> wrote:
> > > 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. > s/Athena/Athens/ > >> >> 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.
