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 :). > > 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. > That makes sense, thanks. What I was looking for was: it is impossible for libraries to "work around" this system by using, say, `dep` to resolve versions using more complex constraints, and then lock those versions in by commit hash for all its consumers. But I now see you've explicitly thought about that, and we can get the best of both worlds - apex modules can lock to commits in order to work around bugs or achieve non-technical goals, but library authors cannot impose arbitrary locks. > >> - 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. > 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. That is indeed what semver requires you to do, but I wonder how often "oopsie" reuploads happen at the same version, and how well/poorly vgo behaves under those conditions. IMO it's probably fine to say "wontfix, don't do that", as long as it's loudly documented. > >> - 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). > Excellent. I expected nothing less from Go tooling, but it's good to know for sure :). > > 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.
