I should add: even though I spent several hours working through these issues, I feel very happy about the process and outcome. I have high confidence that I understand what vgo is doing with my module spec, and that I know how to tweak its thinking in future. I would contrast this with my experience with Glide. Last weekend, I tried to `glide up` this same project, and spent 4 hours trying to resolve the resulting mayhem of diamond dependencies and build errors. I failed, rolled back the change, and decided MetalLB could stay on old code for a while longer. I still have very low confidence that I understand what glide will do when I `glide up`, or that it will produce a working result.
Additionally, some of the time spent is likely the learning curve. As https://github.com/golang/go/issues/24032 illustrates, I was initially confused and had to re-read some of rsc's writing to formulate my plan of action. Despite that, I still spent less time end to end than with glide, and I had a working build at the end of it. - Dave On Thu, Feb 22, 2018 at 11:20 PM, David Anderson <d...@natulte.net> wrote: > This is an experience report onboarding vgo for a relatively complex > project (multiple binaries, vast import tree, tricky unidiomatic imports). > I leave it here in the hopes that it guides other people, and potentially > illustrates places where vgo falls short of great. TL;DR it went pretty > well, modulo a couple of UX speed bumps. > > The result is the `vgo-test` branch of https://github.com/google/metallb/ > . Cloning that repository should allow you to `vgo test ./...`, `vgo build > ./controller`, `vgo build ./speaker`, and a few others. I don't make any > representation that the code does what it should, merely that it builds and > passes tests. > > The resultant go.mod, https://github.com/google/ > metallb/blob/vgo-test/go.mod , is quite messy. This is mostly due to the > number of dependencies that have no semver at all, forcing vgo to use > commit hash "versions". The result is a lot of visual noise in the file, > but hopefully that will improve over time as both vgo and dep nudge people > towards semver releases. > > I encountered two major roadblocks on the road to `vgo test ./...`: the > Kubernetes client library, and mixed case packages. These are > https://github.com/golang/go/issues/24032 and https://github.com/spf13/ > jWalterWeatherman/issues/22 respectively. > > > The Kubernetes client library is a worst case scenario for vgo. It > releases a new major version every 3 months under the same module name, > with real incompatibilities between versions; and it relies extensively on > a transitive version lock to force a specific package selection on its > dependents. Making this library usable from vgo required the following: > > - Fix up client-go in a fork > - Fork github.com/kubernetes/client-go to > github.com/danderson/client-go > - Add a go.mod to the fork, containing only: module " > k8s.io/client-go/v6" > - Update all internal self-references within client-go: perl -pi -e > 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go > - Commit the result, https://github.com/danderson/client-go/commit/ > 7d8481153a9edbf8eacc176ce29f8d58949c3a77 > > <https://github.com/danderson/client-go/commit/7d8481153a9edbf8eacc176ce29f8d58949c3a77> > . Tag as v0.0.0-vgo-prototype-compat and push. > - Make my repository use my fork of client-go: > - Update all uses of client-go to the new versioned package name: perl > -pi -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go > - Require the right version in mod.go: require "k8s.io/client-go/v6" > v6.0.0 > - Replace upstream with my fork in mod.go: replace " > k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go" > v0.0.0-vgo-prototype-compat > > I'm curious how we could upstream the changes I had to make to client-go. > I had to rename module-internal imports, which will break existing non-vgo > uses of the library, but vgo offers no alternative to this renaming that > I'm aware of. It looks to me like there's no graceful upgrade path for this > module. The repo structure works either for pre-vgo clients, or for vgo, > but not both at once. > > The UX was lacking to explain the reason for failures, before I made any > of the changes. Given just my repository, vgo inferred that I wanted v1.5.2 > of client-go (3+ years old), continued resolving dependencies, and > eventually barfed when it found an import for a client-go subpackage that > didn't exist in 1.5.2. The error was simply a bunch of "no such file or > directory", and required some head-scratching to understand what had > happened. Once I understood why vgo was making that decision, and how to > correct it, vgo provided the right tools (mostly replace-with-fork) to > correct the issue without waiting on the library to fix itself. > > > The second issue I hit is github.com/spf13/jwalterweatherman. The actual > repository name in github is "jWalterWeatherman", but everyone (including > the package's author :) ) imports it lowercase. vgo disallows this casing > mismatch. > > To solve that, I just added a require + replacement to "fix" the > case: replace "github.com/spf13/jwalterweatherman" > v0.0.0-20180109140146-7c0cea34c8ec > => "github.com/spf13/jWalterWeatherman" v0.0.0-20180109140146-7c0cea34c8ec > > The version to use in that replacement was hard to come by. Since vgo was > unable to compute the right dependency list without this replacement, it > bailed without giving me any version I might use. The date+hash format is > irritating to construct by hand, but could be trivially lifted into a tool > (perhaps even vgo itself). Instead, I opted to create a separate dummy > module, with a dummy main.go that imported and used the camelCased package, > and run vgo on that. This produced a tiny go.mod with a constructed commit > hash version, which I then used in MetalLB's go.mod. It would have been > nice for vgo to help me a bit more there. > > - Dave > > > > On Tue, Feb 20, 2018 at 9:20 AM, 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. >> > > -- 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.
