Two more use cases of vendor that I would like to keep: - A single audit trail for all go code going into production binaries in a git log. - A single place to enforce upgrades for multiple binaries in a monorepo. Perhaps a top-level meta-module could do the trick?
On Tuesday, February 20, 2018 at 6:42:50 PM UTC-8, Dominik Honnef wrote: > > Hi, > > I'd like your input on two concern I have, one as a tool developer and > one with regard to reproducible builds. > > With go and go get, it is expected that code will not compile until > all dependencies have been explicitly downloaded. Hence, it is > acceptable for tools such as staticcheck to also fail if dependencies > are not present. Vgo seems to change this, by promising the user that > dependencies will be automatically downloaded. Running `vgo build` at > any point will "just work". Tools, however, do not have this luxury, > for multiple reasons: > > - Multiple tools may run in parallel, either via helpers such as > gometalinter, or simply because editors like Emacs launch multiple > tools at once, for example when saving a file. This is likely prone to > race conditions. File locking may be an option, but file locking is > known to cause erratic problems on networked file systems, or be > outright unsupported. > - Fetching the dependencies, e.g. via 'vgo build', has the side-effect > of modifying the go.mod file. This is probably unacceptable for tools > that are run automatically, without the user's express wish to add new > dependencies to the go.mod file. > - If we do find a solution to these two problems, we'd probably still > want a 'vgo get' (with no arguments), to just fetch the dependencies, > without also incurring a costly build. > > In my opinion, tools should behave as closely as possible to (v)go > build, so that users can operate on a single set of expectations. > > My second concern is regarding the promise of getting rid of the > vendor directory. Reproducible builds not only depend on versioning, > but also on ensuring that code doesn't go away, be it due to server > downtime or more permanent reasons. Vendoring makes this rather easy: > add your dependencies to vendor and commit them, and your project is > now self-contained. Vgo seems to discourage this practice. Can you > suggest an alternative that is as straightforward as vendoring? All > other solutions - which amount to various forms of proxies and mirrors > - are significantly more laboursome. > > I have noticed that currently, vgo downloads dependencies into GOPATH. > Are there any plans to instead store them with the module itself, > possibly in a way that facilitates committing them to version control? > > On Tue, Feb 20, 2018 at 6:20 PM, Russ Cox <r...@golang.org <javascript:>> > 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...@googlegroups.com <javascript:>. > > 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.
