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.
