It’s time for the
News and Such
Or at least, it’s big for us, though users may not notice it quite so much. The main differences are:
dep ensure -addwas 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
dep ensure -vendor-onlyand
dep ensure -no-vendor, which are dual to each other, let you limit
ensureto doing only part of its typical work.
-vendor-onlycan 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
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. 🏖
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"
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
[[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
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:
- Specifying a single version,
dep ensure -updateuseless for that dependency, and provides negligible value over simply relying on
Gopkg.lockfor stability in your versions.
- 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:
- We merged @karrick’s filesystem tree hashing algorithm that he’s been working on since GopherCon. This is the foundation of
vendor/verification, which will make
depa lot faster when
dep ensureno longer has to regenerate
vendor/on every run.
- We started writing out
vendor/concurrently. Anecdotal numbers suggest a 6x speedup!
- @spenczar added support for automated conversion of vndr metadata. (Docker uses this format)
- @ebati made
dep ensure -vendor-onlywork even when there’s no code in your project tree. This can be super handy for smart Docker image layering.
- @ilovezfs got
depinto Homebrew and @AlekSi let us know- woohoo!
- We improved feedback and input validation on a number of fronts.
Plus a couple dozen more specific bug fixes, and numerous documentation improvements. And, if you haven’t looked at the README recently, you should!