It’s time for the dep roundup!

News and Such

The big news this time around is clear: we finally landed the overhaul of dep ensure that we’ve had specced out since May! 🎉🎉

Or at least, it’s big for us, though users may not notice it quite so much. The main differences are:

  • dep ensure -add was introduced, to facilitate adding new dependencies. This should address longstanding grievances about the chicken-or-egg problem of trying to add an import in order to add the dep, but autocomplete tooling not working because the dependency isn’t yet in vendor/.
  • dep ensure -vendor-only and dep ensure -no-vendor, which are dual to each other, let you limit ensure to doing only part of its typical work. -vendor-only can be particularly useful for building container images.
  • dep ensure, without any additional flags, no longer takes any arguments.

This new CLI UI is available as of v0.3.0. We’re very excited about this, as we now feel comfortable saying that it is safe to script on top of dep! Or at least, dep init and dep ensure - significant changes are still coming for dep status.

Adoption really seems to be ticking up, which is lovely! If you’re struggling with the switch, please feel free to mention @sdboyer, @ibrasho and @darkowlzz in the relevant GitHub issues: that’s me, and two of dep’s wonderful subsystem maintainers. Of course, that’s in addition to Slack, the mailing list, and issues directly on the golang/dep repository.

On a different front, we’ve also got a few folks working on a preliminary spec and very early prototype for registries. That discussion is aiming for something that can satisfy both the needs of companies to run their own private services for code hosting, version-blessing, etc. (basically, a lot of the “enterprise goals” we’ve been discussing), but also be able to function as a public registry, a la crates, npm, rubygems, etc.

I know this is a topic on which many people have many feels. It’s also a sufficiently complex topic that just having an unstructured conversation tends not to be wildly productive, as the aforelinked issue demonstrates. So, as we did with the package management committee last year, we’re going to work through this spec doc a little more, to the point where we feel like it covers the essential bases, without actually making any real commitment to it. We’ll then open it up, the torrent of opinions can rain down, and we can figure out where to go from there.

One last thing on the horizon: we’re planning to absorb dep prune into dep ensure. As far as I can tell, this should pretty much just be categorically good for everyone.

Quick note: I’m going to be on vacation for all of next week. That’s real vacation, the kind where I don’t actually check in. 🏖

Hot Topics

Let’s talk about a thing: “implicit caret operators.”

If you have a Gopkg.toml that looks like this:

[[constraint]]
  name = "github.com/foo/bar"
  version = "1.0.0"

Then dep will interpret "1.0.0" as meaning, “greater than or equal to 1.0.0, but less than 2.0.0, and not including any prerelease versions in that numeric range.” This is also expressed as "^1.0.0" - that caret operator. It’s implicit, in that if you don’t specify an operator, we assume you meant caret; this is almost certainly counterintuitive, as most folks would imagine the = operator is implicit. If you want to specify 1.0.0, and only 1.0.0, then this is your Gopkg.toml:

[[constraint]]
  name = "github.com/foo/bar"
  version = "=1.0.0"

A community member opened an issue with some entirely reasonable questions about why we made this choice. I gave a partial answer, and I do eventually need to do an entire, dedicated blog post on this. But, in the meantime, I want to briefly highlight it here, as this is a really important topic, and one that goes to how we would ideally like to see people using dep.

We have implicit ^ instead of = as a nudge: it makes the recommended approach also the obvious path of least resistance. Carets are the recommended approach for two reasons:

  1. Specifying a single version, =1.0.0, makes dep ensure -update useless for that dependency, and provides negligible value over simply relying on Gopkg.lock for stability in your versions.
  2. Unnecessarily tight constraints are the main cause of conflicts while resolving the depgraph. Such conflicts are one of dependency hell’s biggest circles. When the tool defaults to more open constraints, then users following that path of least resistance will create a friendlier ecosystem.

The first point impacts dep users directly - less futzing with files, more running of commands. But the second point is the really important one. dep has made a calculated bet on the idea that it’s worth risking that form of conflict resolution dependency hell, because the alternative is at least as bad. But whether our ecosystem ends up happy or conflict-ridden will be, in part, an emergent property of the choices we all make as individual project maintainers.

Community Attention Needed!

Quickly, first - we’re still looking for more maintainers! Or, at least, I could use a lot more help with PR review 😄

This time around, I’d like to do something a bit odd.

dep has a lot of momentum and good will behind it now. We’re really, really proud of that. But, now that the the prevailing winds are blowing dep’s way, it’s easy for people to feel like their concerns might be dismissed, or even shouted down by the ‘faithful’. That may be especially true for larger-scale issues, or issues relating to process, more than software; it’s easy enough to just open issues about the latter.

So, the community theme for this status update is: air your grievances. Obviously this isn’t an invitation to disregard the Code of Conduct, but I want to make sure folks everybody feels like they’ve got a chance to be heard. dep is supposed to be for the Go community, which means we’ve gotta hear from everybody.

Let’s do this on the reddit thread for this post.

Stuff We’ve 🚢ed

Busy, busy Gophers, we’ve been! Here are some big ticket items, apart from landing the big dep ensure refactor:

Plus a couple dozen more specific bug fixes, and numerous documentation improvements. And, if you haven’t looked at the README recently, you should!