[go-nuts] Re: go modules and vendor: redundant features?
Vendoring MUST stay. Athens is another piece of software that has to be set up and keep update. Venoring solves this porblem and ols the one when dependencies go missing. On Saturday, November 17, 2018 at 5:33:55 AM UTC+1, Henry 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. 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.
Re: [go-nuts] Re: go modules and vendor: redundant features?
The main issue tracking vendoring-related discussion is https://github.com/golang/go/issues/27227 On Thu, 22 Nov 2018 at 09:08, wrote: > > Vendor must be kept for when dependencies are no longer available online. > > On Saturday, 17 November 2018 04:33:55 UTC, Henry 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. 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.
[go-nuts] Re: go modules and vendor: redundant features?
Vendor must be kept for when dependencies are no longer available online. On Saturday, 17 November 2018 04:33:55 UTC, Henry 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. 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.
Re: [go-nuts] Re: go modules and vendor: redundant features?
> 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. For what it's worth, I don't believe that tooling is covered under the backward compatibility promise, so it is possible to remove things without a new major version bump. Of course, this would have to be done with care, but it's not out of the question. I know that this is a bit of an aside but it's worth keeping in mind. On Mon, Nov 19, 2018 at 4:40 PM wrote: > > I recall reading from Russ Cox that vendoring will be removed in the > future and be replaced by explicit caching with modules. > > -- > 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. > -- Tyler Compton Student of Software Engineering Arizona State University -- 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.
[go-nuts] Re: go modules and vendor: redundant features?
I recall reading from Russ Cox that vendoring will be removed in the future and be replaced by explicit caching with modules. -- 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.
