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.

Reply via email to