On Tue, Feb 20, 2018 at 4:07 PM, David Anderson <d...@natulte.net> wrote:

> On Tue, Feb 20, 2018 at 11:37 AM, Russ Cox <r...@golang.org> wrote:
>> On Tue, Feb 20, 2018 at 1:55 PM, David Anderson <d...@natulte.net> wrote:
>>> I love this. I want it now.
>> go get -u golang.org/x/vgo :-)
>> I've struggled with `glide` and `dep` dependency hell a lot in my Go
>>> projects (especially those that use the Kubernetes client library, which
>>> abuses "I, the library author, can define byzantine constraints on my
>>> users" to the extreme). The way I've described it informally is that
>>> traditional "arbitrary version selection" algorithms create the wrong
>>> incentive structure for library authors, in the sense that they have all
>>> the power to lock versions arbitrarily, but bear none of the pain
>>> associated with their decisions - instead, the binary author at the apex of
>>> the dependency tree gets that pain. "Authority without responsibility" is
>>> the death of many incentive structures.
>> Yes, I'll make that point again in tomorrow's posts elaborating minimal
>> version selection, but I think this is probably the most important
>> algorithmic policy detail. You get total control over your own build. You
>> only get limited control over other people's builds that happen to import
>> your code.
> Big +1. I'm curious about your ideas on how to manage the transition from
> a glide/dep world to a vgo world. I look forward to reading more about
> that, assuming you have an article queued to discuss that facet :).

I don't have an article about this. There are two parts to the answer. The
first is that vgo reads all these tools' lock files and records the things
listed there are minimum requirements, as a starting point. I expect this
will be good enough for many projects. For example, on Tuesday when vgo was
first released, before anything had time to convert, you could git clone
upspin or dep, cd into the checkout (anywhere, not just in GOPATH), and
start working. Vgo seeded go.mod with the Gopkg.lock file. The second part
is that, as Sam posted <https://sdboyer.io/blog/vgo-and-dep/>, we are
trying to work out a way to contract him to build tools to help with more
complex conversions.

One thought that I hope you'll cover there: immutability. Reading through
> the vgo tour, it seems to assume that once v5.6.7 has been released, that
> .zip and its declared dependencies will never change.

You've probably seen this by now, but: research.swtch.com/vgo-repro.


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