I don't really know much about the other tools but afaik the difference is more in the fact that Gb is more similar to other build systems in other languages. It focuses on making the current thing you are working on easy and simple to build rather than being a tool to work around the strangeness that the vendor thing has become. That is what is so good about it. I can use it without needing to bother about what weird hierarchical vendor folder gets imported where. Probably a bit naive but it has worked so far and it has been so nice.
OT, I think the whole recursive vendor folder handling is a mistake and probably one we will regret unless we fix it. Much better would have been to just embrace semver, stuck to any of the numerous simple existing dep file format and it would have been done, simple and understandable. On Sat, Jul 16, 2016, 11:44 Florin Pățan <florinpa...@gmail.com> wrote: > I know that talk very well since I'm the one Dave called a "compiler" at > ~5:14. > > All the arguments about what's reproducible or not get muted when using > vendoring. However, in order for that to be more effective, releases for > various packages should be versioned and that controlled via the dependency > management of your choice. You can do this with revisions but eh, not very > fun to do it. > > On Saturday, July 16, 2016 at 10:23:00 AM UTC+1, Mauro Toffanin wrote: >> >> On 16/07/16 01:43, Florin Pățan wrote: >> > I feel this is a controversial statement. >> >Godep can do this just as well, in fact any vendoring tool can do this, >> > as long as you commit your dependencies. >> >> That is not true. Dave Cheney explained it very well at GDG Berlin >> Golang DevFest: https://www.youtube.com/watch?v=c3dW80eO88I (see at >> ~15:00) >> >> Godep, and other package managers too, are at best naive work-arounds >> shoehorned on top of 'go get', while gb is a genuine solution to the >> problem of reproducible builds in Go. >> >> In particular, I found the concept of 'import rewriting', used by >> countless of package managers, quite irksome and in direct opposition to >> the very same concept of a "reproducible build". You have no idea how >> many times I have been bitten by the disruptive behaviour of the 'import >> rewriting' of those package managers, much to my frustration and dismay. >> >> > Import path rewriting is awful but Godep doesn't need that. Now with the > "vendor/" folder (which is proposed by Go not GB) this is even better since > there's no more GOPATH fiddling. It may have required rewriting in the > beginning, I don't know, but since I've been using it (around 3 years) I > never rewrote import statements. I cannot speak about other tools but that > seems like a problem which can be avoided by reading how the tool works. > > >> >> >> > Can you plead elaborate how using gb changes an6 of this? >> >> There is no need for me to elaborate. You can find all the answers to >> your questions here: https://getgb.io and >> https://github.com/constabulary/gb >> > > I appreciate you like gb, it's an interesting tool, but you cannot explain > why it's different compared to other solutions when it comes to those two > particular problems mentioned by you so I'd kindly suggest reading more > about it. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
