For repeatable builds there are many ways and tools that work fine, Gb is not unique in this respect.
I don't get why this should be a controversial topic however. It seems to be an issue only in the go community. In all the other languages (newer more modern anyway) it is considered a solved problem. Sure different tools pop up now and then but they all work in the same general way. I am sure there is a reason but why can't we just settle on the same idea that everyone else is doing? Applications and libraries would all then use the same principal way of resolving dependencies and different tools could handle conflicts in whatever way the author likes. Vendoring or not it would work regardless. On Sat, Jul 16, 2016, 13:51 Florin Pățan <florinpa...@gmail.com> wrote: > > On Saturday, July 16, 2016 at 11:34:12 AM UTC+1, Mauro Toffanin wrote: >> >> On 16/07/16 11:44, Florin Pățan wrote: >> > 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 are way too emotional about this topic, and a clear victim of the >> Dunning-Kruger effect. Cheney has already explained all your questions. >> >> > Thank you for bringing up my condition, I'll make sure I treat it, it > sounds like something dangerous (nice insult by the way). > > Dave has explained his own reasons about this while unfortunately ignoring > some aspects which actually are crucial. > The distinguishing factor between gb and other solutions is that it allows > for organizing projects into individual workspaces, which for some is > useful. However this means that now I'm forced to use it if I want to > compile a Go app, which is in opposition with using the standard Go tools > to do it (yes, I'm sure you can probably workaround it and still compile > it). > > The point is: > - for reproducible builds one needs always the exact dependencies, which > is achieved with the vendoring approach (and commiting the source) > - for reliable builds I don't get how gb is any different than go build > - you cannot provide arguments for why gb solves any of this while other > tools don't (if you take into account the parts that are left out) with > your own words, which combined with the: just look at what Dave says, > results in the assumption that you do not have the required understanding > of these issues, thus my recommendation to look at what they mean. > > Also, I was asking for an explanation on why this is different because I'm > too stupid to understand it but I guess I'll remain as such since I still > don't have an explanation for it after all this exchange. > > Meanwhile, if you or someone else wants too look into this, there are a > few resources on this: > - > https://docs.google.com/document/d/1xrV9D5u8AKu1ip-A1W9JqhUmmeOhoI6d6zjVwvdn5mc/edit?usp=sharing > - https://github.com/sdboyer/gps/wiki (docs for the tool which resulted > from the above document and the discussion based on it, > https://github.com/sdboyer/gps) > - a Slack channel dedicated for discussion on this: > https://gophers.slack.com/messages/vendor/ (you can get the invite from > here: https://invite.slack.golangbridge.org/ > > I'm not interested in a bout, sorry :) >> > > I had to look up what bout means and so today I've learned, thank you. > > > P.S. See why I said this is controversial? > > -- > 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.
