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.
Questions that arose during reading:
>
> - In the "defining Go modules" section, you say: "Although semantic
> versions are strongly preferred, referring to specific commits will be
> supported as well." Then, you specify that such commits order before
> v0.0.0. To me, this suggests that this feature will be useless, because any
> non-trivial example will have *some* semver constraint somewhere in
> the dependency tree, such that in practice commit-hash versions will always
> be overridden by minimal version selection. I don't have a solution to this
> (other than removing support for commit-hash versions), but it seems like
> it's something to think about
>
> That's by design: if v1.2.3 is the latest tagged version and there's some
experimental new stuff that you choose to depend on, and then vgo has to
decide between those two requirements coming from two different
dependencies in a larger build, I want it to pick the tagged one. That
said, for builds of your own module, what you'd do is define that you want
to replace the current latest (say, v1.2.3) with a different commit. In
go.mod you'd say:
replace "p.xyz/foo" v1.2.3 => "p.xyz/foo" commithash
and then the version selection would transparently drop in commithash as if
it were really v1.2.3, so that it would win over v1.2.2, but not v1.2.4. I
suppose you could even make up a very large number like v1.9999.0 and then
depend on that. But again the replacement only applies to your build, not
to other builds using your module.
>
> - Modules as zip archives: how do I discover which versions are
> available? Minimal version selection seems to rely on being able to list
> the version continuum for a module, so that constraints can be applied.
> What's the expected way to do that?
>
> Yes, you have to have a way to list them. I'll write more about that
Thursday.
>
> - Writing module files sounds like a job for a machine, in cases where
> I don't care which version gets used. Can `goimports` (or a new sibling
> tool) be taught to update module definitions based on my code?
>
> Goimports just needs to put the import in. "vgo build" will see the new
import and take care of the rest. It rewrites go.mod for you (and formats
it too, of course).
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.
