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 .
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,
, 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 and 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 to
      - Add a go.mod to the fork, containing only: module ""
      - Update all internal self-references within client-go: perl -pi -e
      's#""' **/*.go
      - Commit the result,
      . 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#""' **/*.go
      - Require the right version in mod.go: require ""
      - Replace upstream with my fork in mod.go: replace "" v6.0.0 => ""

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 The actual
repository name in github is "jWalterWeatherman", but everyone (including
the package's author :) ) imports it lowercase. vgo disallows this casing

To solve that, I just added a require + replacement to "fix" the
case: replace ""
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 <> wrote:

> Hi everyone,
> I have a new blog post you might be interested in.
> 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
> For more options, visit

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 
For more options, visit

Reply via email to