It’s time for the dep roundup!

News and Such

First, this round-up is clearly absurdly overdue, as it’s been nearly two months since my last one - sorry! Many things interceded, particularly planning discussions with the Go team and prep for the closing keynote at GopherCon. Peter Bourgon is helping me write these, now, so it should be harder for me to fall behind. GopherCon was, by the way, a huge success for all things dep - especially the hackathon we ran on community day!

Despite my lack of updates here, though, progress has been accelerating steadily. I can’t possibly summarize everything’s that’s happened in the last couple months, but here are some major points:

We’ve had quite the flurry of activity and new contributors coming off of GopherCon, and we’re finding a new rhythm with all the new folks. This has meant a lot more bug fixes distributed all across dep, as well some significant progress on desperately needed documentation. To that end, we’ve cut a v0.2.0 release. If you’re building dep into your CI workflow, it’s probably preferable to rely on these latest released versions over go get, if your CI flow can deal with the added inconvenience.

Apart from these more ad-hoc changes, the main roadmap goal I’m trying to push efforts towards now is stabilizing the CLI interface. The most noticeable change will be that dep ensure will gain an -add flag, which facilitates both initially introducing a new dependency, and appending constraint rules into Gopkg.toml. dep ensure will, as a complement, lose the ability to take any project arguments without either -add or -update.

While this PR will generally stabilize the CLI interface, that “stabilization” guarantee here isn’t as strong as with the backwards-compatibility promise on Gopkg.toml and Gopkg.lock. We’ll certainly try hard to avoid breaking changes, but some future changes may break some scripts. We aren’t currently planning on any changes in a class that would cause widespread problems, though, so breakages are likely to be restricted to scripts that operate on edge cases.

Finally, a note on communications. Some folks have requested that we move discussions back towards the Go package management mailing list, especially as an alternative to Slack. I want to support this, but I also find Slack valuable, and know that, just personally, I won’t be able to support the community in the same way from a mailing list as I can in a chatroom. So, I’d like us to experiment with the following loose rules for where different discussions happen:

  • I plan to start utilizing the Go package management mailing list for questions that may be broader than can be effectively discussed on GitHub issues. Other folks are, of course, welcome to use the mailing list however they want.
  • GitHub issues should generally be for more narrow, specific discussion; the lack of threading can make it really difficult to follow conversations there.
  • Quicker questions, guidance, or knowledge transfer are always welcome on the Gophers Slack in #vendor.

As always, we try very hard to be friendly and welcoming! But, please feel free to DM me on Slack or Twitter if you don’t feel comfortable asking questions in these other venues.

Hot Topics

One suggestion Peter made is that we expand these status updates to include a brief answer to a question or two that we’ve seen come up frequently. For our inaugural topic, here’s a bit about the problems with multi-project workflows.

One common workflow is when you’re working on a main project and one or more of its dependencies concurrently. This often happens when you want to test changes to a dependency before submitting them upstream. dep has somewhat fragile support for this at the moment, and the team is committed to finding a simple. reliable answer with minimal harmful side effects. But in the meantime, community member @JelteF has provided a nice tool called virtualgo. If you find yourself in this situation fairly frequently, take a look.

Community Attention Needed!

There’s been so much going on during and since GopherCon that I haven’t really had a chance to put together something that we can readily incorporate a bunch of community feedback around. However, we have 30 (as of this writing) open help-wanted issues right now. Some have been claimed, but plenty haven’t - those issues are the main avenue we keep open for people looking to get involved with the project!

Stuff We’ve 🚢ed

We’ve merged more than 80 pull requests since the last dep status update, with 20 of those coming in the last week. There’s no way I could meaningfully cull from that huge pool. So, instead, here’s a list of the GitHub handles of all our first-time code contributors in that period:

  • @farcaller
  • @sebdah
  • @DDRBoxman
  • @matjam
  • @otoolec
  • @grepory
  • @jgeiger
  • @afeld
  • @mikijov
  • @dtan4
  • @marwan-at-work
  • @dlespiau

Thankyouthankyouthankyou! In the next update, when the PR list is more manageable, I’ll go back to highlighting significant individual changes.