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 <[email protected]> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
