A sidenote is that there seems to always be issues with using kubernetes
Is it structured very un Go-ish?
Very nice writeup!
NB: I was also hit by the casing issue with the same viper dependency.
fre 23 feb. 2018 kl 08:28 skrev David Anderson <d...@natulte.net>:
> 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
>> - Add a go.mod to the fork, containing only: module "
>> - 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,
>> . 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"
>> - Replace upstream with my fork in mod.go: replace "
>> k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go"
>> 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
>> 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"
>> 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.
>>> I'll try to watch this thread to answer any questions.
>>> 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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.