FWIW, go build in versions >= 1.6* is basically equivalent to what GB buys us just with a different structure for the vendor directory (i.e /vendor vs /vendor/src in GB). The gb-vendor plugin is a jewel in its simplicity and makes fetching/managing vendored packages very easy, which is what I love about GB as a build tool specifically when the end product is a binary. If I were authoring a library I'd definitely stick to the go tool chain given that GB projects aren't go gettable.
- Will On Sat, Jul 16, 2016 at 5:44 PM, Henrik Johansson <dahankz...@gmail.com> wrote: > Well they have issues too of course. The most recent left-pad debacle is > most striking. > > In general they do have support for versions all of them. Not all are > SemVer, the older seems more fluid on the interpretation of what is a valid > version but they have it. There are often many or at least a couple of > different tools for each language for example Maven, Gradle, SBT, Ivy etc > in the Java landscape. Ruby has a number of such tools as does python. In > the static compiled family the two outstanding examples are Haskell and > Rust. > Cabal has had it's problems but the community seems happy with it. The > Rust people are all on board with Cargo it seems and it is afaik the > solution that would work best for Go to look at. It is in essence a > declarative file with dependencies (and some extra stuff) which would be > super easy for Go to adopt. Even having the go tool do it seems very > easy. The different tools behave differently in how they work to resolve > compatible versions. Some have a range notation, some have default > selection and some bail. Bailing or allowing the user to choose seems the > best possibly with a range notation. > > This you are no doubt aware of already, I just wanted to list where I come > from when I say that it is considered solved. > Not that all possible kinks are hammered out but that it seems to work in > a way that a large number of people are OK with. > > Personally I really like the vendor concept but the thing where one of my > deps can have the same type as a dep as I do but from my perspective the > types of these two are different when they really are the same seems very > fishy. > Flattening makes it better but then something can break because the wrong > "version" was chosen. > Having a common versioning scheme would make this much easier and safer > even if we occasionally would run into the diamond problem. At least we > would know that there was an issue and can take steps to fix or work around > it. > > Having versions would also not hinder tools to resolve and fetch all deps > every time if they want to nor does it stop vendoring. In my mind what we > have today is hidden versions without any easy way to see or choose what we > want. > Having the go tool be version aware may be a too invasive change but it > would not be hard. > > I don't know, I feel as though I am missing something. It feels so obvious > to me that when you guys don't see it the same I start wondering what I > missed. > > Hope it makes some sense. > > > > On Sat, Jul 16, 2016, 19:13 Ian Lance Taylor <i...@golang.org> wrote: > >> On Sat, Jul 16, 2016 at 5:29 AM, Henrik Johansson <dahankz...@gmail.com> >> wrote: >> > 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. >> >> My understanding is that what other languages do also has problems. >> If there is a clear solution here, I certainly think we should adopt >> it. >> >> Can you explain what it is that other languages do, and how we should >> change to do the same thing? >> >> Ian >> > -- > 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.
