Actually it seems viper imports it with lower case. I don't remember if import paths are to be considered different if they only differ in case.
ons 21 feb. 2018 kl 09:04 skrev Henrik Johansson <dahankz...@gmail.com>: > 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.
