Unfortunately, the rules also create some new perverse incentives, with some, IMO, nastier failure modes and remediations. That's one of the things i'll be elaborating on in my doc (hopefully) next week.
That said, one of the points Russ and i agree on is that dep does allow more expressiveness than is wise. On Tuesday, February 20, 2018 at 1:55:59 PM UTC-5, David Anderson wrote: > > I love this. I want it now. > > 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. > > The proposed rules around semver and minimal version selection address > every pain point I've had so far, by aligning available authority with the > responsibility of the library authors: tell me what versions definitely > will *not* work, and I'll take it from there. > > 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 > - One alternative I considered, but discarded, was to order all > tags and commits by their date, and run minimal version selection on > that. > However, this doesn't work because semver tag dates don't grow > monotonically - you might have 0.1.2 released after 0.2.0, which leads > to > confusing behavior to the user - why did 0.2.0 get selected when 0.1.2 > was > a "better" minimal version? > - 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? > - 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? > - No GOPATH required: YES! Thank you. I share Zellyn's question on > what happens to `go install` in this world. Does it go away? Does it > install to some new $GOBINARYINSTALL or somesuch? > > Haven't read the vgo tour yet, it may answer some of these. I may be back > with more :) > > - Dave > > > On Tue, Feb 20, 2018 at 9:20 AM, Russ Cox <r...@golang.org <javascript:>> > wrote: > >> Hi everyone, >> >> I have a new blog post you might be interested in. >> https://research.swtch.com/vgo. >> >> 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 golang-nuts...@googlegroups.com <javascript:>. >> 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.
