gb feedback

[David Bariod]

Hello,

I just discovered gb the last few days, and basically for my workflow it seems to solve all my issues regarding go dependency management.
I just wanted to publicly say "thanks for the good job" to Dave.

Has anyone completely switch from go to gb and what would be the feature which would be needed to be added to this tool ?

Regards,
David Bariod

[Henrik Johansson]

I haven't completely switched but I use Gb for larger projects. I don't really miss anything except for perhaps Atom integration.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Cheney]

Thanks David.

I'm glad it's useful for you.

I use gb as my daily driver for working with go code. Save the work I
do on the std library, I don't use the go tool at all.

[Mark Petrovic]

I'm switching to gb for my projects, which number in the upper teens to maybe twenty.  The ability to be free from the GOPATH became important to me, as a pre-gb-based project might contain import paths intending to point to packages in those very same projects, but that require the project to be checked out in just the right location within the GOPATH.  When I encountered that specially-located requirement, I knew gb was the way to solve it.  Now, it doesn't matter where I clone my code; it just builds.  This becomes even more important when someone else clones the code, as they don't have to locate it in a special place for imports to work.

[Matt Farina]

For context, I write Glide.

GB isn't just about dealing with dependencies but a separate build tool that frees you from the GOPATH.

First, I really like the idea of being free from the GOPATH. The GOPATH is the #1 WTF element I need to teach new Go developers. It's a problem.

If you look at early versions of Glide we tried to break free from the GOPATH but found there are just too many things that break due to the internals of how the go toolchain is written. When vendor/ directories came along we switched because it offered the closest thing we could get.

So, I'm supportive of tools and changes allowing to break free from the GOPATH.

Second, If GB supported version ranges, resolution, and typical metadata I would start doing backflips of joy. It's some of the package management features I want that I miss there. I have dreams of making Glide compatible with GB but I don't have the time anytime soon.

Third, because GB isn't maintained or developed with the same level of effort as the go toolchain I can't ask the people around me to switch. If it was I would suggest more companies and projects use it. So, if you're interested in that kind of problem please help Dave out. Really.

I'm positive on GB. I hope it becomes a viable solution for more people (due to all the reasons that enterprises hold back from things like that).

[luc.hei...@gmail.com]

On Friday, July 29, 2016 at 6:34:37 PM UTC+2, Matt Farina wrote:

> GB isn't just about dealing with dependencies but a separate build tool that frees you from the GOPATH.

I really need to chime in here and profusely thank Dave Cheney for his work on gb, being free from the utter nonsense that the GOPATH is has been, as excessive as it sounds, liberating to say the least.

So yeah, thanks Dave :)