I really like this, except for the claim that it the blog post that it will eliminate vendoring and deprecate GOPATH and the problems that will cause for backwards compatibility for things that are currently using them. If this is going to result in removing language features (ie. vendoring), shouldn't it be in Go2, not Go 1.11?
I've abused vendoring in the past for things like fixing bugs in upstream libraries that I use where the maintainer hasn't been responsive to pull requests and, while the "replace = .." of vgo is definitely a better solution, removing vendoring would mean that I would need to go through every repo I have to ensure they keep building once this goes in. The other question I have is: where does the module name come from if you don't have a "// import" comment on the package, since it can't be filesystem based (because you're explicitly outside of GOPATH..) - Dave On Tue, Feb 20, 2018 at 12:20 PM, Russ Cox <r...@golang.org> wrote: > Hi everyone, > > I have a new blog post you might be interested in. > https://research.swtch.com/vgo. > > I'll try to watch this thread to answer any questions. > > Best, > Russ > > > > -- > 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. -- - Dave -- 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.
