I am currently running `vgo build` on a decent sized project that has a few dependencies.
It bailed on import case it seems: import "github.com/spf13/jwalterweatherman": module path of repo is github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman (wrong case) This is a transitive dep and it seems it indeed mixed upper and lower case. Does vgo assume lower case? ons 21 feb. 2018 kl 06:46 skrev <je...@samsara.com>: > 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> 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. >> > > 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.
