Golang support

[greysteil]

From @jbreitbart on April 8, 2018 12:14

Do you have any plans to support golang with dependabot? I know it is probably not the ideal time with dep / vgo thing going around, but maybe once this is sorted out?

Copied from original issue: dependabot/feedback#125

[greysteil]

Short answer: we're really keen to support golang and will definitely get to it in the next few months.

Long answer: we've been waiting for dependency management to settle in Go for a while. Until a few weeks ago we were getting excited about dep, and planning to add support for it imminently. Then the vgo thing happened, and we decided to hold off for a little longer. In the meantime we kicked off some meaty projects (Rust, security advisories, live updates) that we need to polish before kicking off anything new, but we'll be looking for the next challenge in May/June.

Hope that helps, and sorry for the delay on this one. If you're super keen for Go support then Dependabot Core is open source, and we could start a discussion on an implementation over there?

[greysteil]

From @jbreitbart on April 9, 2018 22:55

I am afraid I don't speak Ruby 😄, but if you need someone to help you test it feel free to get in touch.

[greysteil]

From @JeanMertz on April 25, 2018 20:31

One more vote for Golang 👍 Honestly, looking at the number of projects out there already supporting Dep, I would go for that. It's the closest "production ready" package manager with a somewhat official stamp of approval.

I suspect it'll be a while before all current Dep projects are migrated to the new vgo way-of-working anyway.

[greysteil]

Thanks @JeanMertz, and that's my hunch, too.

[will-swu]

waiting for go before we adopt this service.

[greysteil]

@will-swu - using Dep or something else?

[will-swu]

Yep, we use Dep.

[key]

We use Dep too. Waiting for golang support :)

[fubarhouse]

I use dep & vgo, and I'd be interested in seeing support here.

[hairyhenderson]

Using dep over here too, would love to see support!

[greysteil]

PR to add Go support (just a placeholder for now, but will be written over the next few weeks) is here. Any comments / advice appreciated.

[greysteil]

Dependabot now supports dep! 🎉

https://dependabot.com/blog/go-support

Would love your feedback. (And I appreciate updating to dep v0.5.0 on the day it comes out, and before it's on homebrew, is a pain - sorry!)

I'm going to close this because I'm feeling triumphant, but that doesn't mean I've forgotten about vgo.

[fubarhouse]

@greysteil,

I've noticed my first PR only changes my lock file - the toml file remains out of sync. This is not what I would expect - I don't know if this is by design, but I feel I should let you know.

See fubarhouse/drubuild#45 for the full details.

Note the following version numbers explicitly mismatch:

• https://github.com/fubarhouse/drubuild/blob/master/Gopkg.lock#L4
• https://github.com/fubarhouse/drubuild/blob/master/Gopkg.toml#L24

[greysteil]

Thanks Karl - that's helpful feedback.

At the moment Dependabot is treating all Go code as if it was a library, so doesn't want to change the Gopkg.toml unless it has to (and if it does, does so by widening the range). I think that's the right behaviour for libraries (let me know if I'm wrong), but it's definitely not the right behaviour for apps.

My plan is to make the above configurable, because I don't think there's any way that Dependabot can tell whether it's working on an application or a library (again, correct me if I'm wrong).

[fubarhouse]

Well, by finding package main, you can identify an application from a library.

I think that's okay - but if it was configurable that would definitely fit the bill for ever scenario - especially when vgo/module support eventually comes alone. 👍

Side-note: the blog post does advertise the change of Gopkg.toml.

Good work!

[greysteil]

Ah, good point - I can tell if it's a library just by checking for the presence of a main.go! I'll get that changed now. 🎉

[fubarhouse]

You may also come across outliers where package main is contained in other files, such as app.go.

The package name is not guaranteed to match the file name.

This however is considerably unlikely.

[greysteil]

Good to know. This change is deploying now and will give more intuitive behaviour. 🎉